Draft: main/postmarketos-base: don't depend on alpine-base

This is one possible solution to start cleaning up and preparing for the systemd branch. One of the problems there, is that alpine-base hard-depends on openrc. The solution in that branch was to fork and change the dependencies of the package. And we had the idea that maybe that would flow upstream. However, I had a look upstream, and that might be harder than expected because there is quite some complexity dealing with other things like devd several virtual providers around. I've still sent an MR, but not sure how will it be taken.

If that does not fly, the solution here is to take what's interesting for us from alpine-base into postmarketos-base, and disregard the rest. Then we can just have our pmb_select or equivalent packaging hack to select openrc or systemd. I'd rather have something nice integrated in alpine, but if that does not fly, I'd say this solution is better than forking alpine-base. The virtual for systemd is not implemented yet, so DON'T INSTALL this, as openrc will mostly likely be removed and the system will break down.

EDIT: Since upstream is too slow, I've split the busybox part of the MR into https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/65144 and then we can remove the dependency here

TODO:

• Move /etc/os-release to /usr/lib/os-release per !5026 (comment 1892186184), including symlink
• Implement postmarketos-base-init, similarly to how we do the audio-selection subpackages, or any other way that the systemd team is discussing to implement selecting systemd or not selecting systemd.
  • @craftyguy decided that pmb_select won't work. pmbootstrap will need to choose based on user/UI preferences. since other pmos-base-init providers might live in other repos (like extra-repos/systemd), pmb_select won't really work here
• Possibly stop providing /etc/issue file? It's optional and does not provide super much value
• Find a solution for packages patched in alpine to use /etc/alpine-release file. It seems to me like all patches are just used to identify whether they are running alpine. That should rather be done reading /etc/os-release. That's what the file and the standard is for! This might require some work
  • @craftyguy decided that this is fine to ignore for now, because its usage falls under one of the following:
    1. it's used at compile time, so not something we care about since these packages are built by Alpine, but miiiiiiiiight be a problem if we fork one
    2. alsaconf uses it at runtime, but there's no logic in the app to do anything conditionally when it's set to Alpine. the aports patch to add a test for /etc/alpine-release doesn't add anything to actually use distribution=alpine, so it's effectively a noop
    3. Rest of usages of /etc/alpine-release are in mkimage and other tooling specific to Alpine that we do not use
• Figure out if we need /etc/secfiles.d/alpine, and drop alpine-release dependency
  • @craftyguy decided to just drop alpine-release and ignore the secfiles.d thing. It may not even be correct for pmOS (we fork some packages, and maybe include others), and we aren't using any scanners that use these files. So let's revisit this in The Future.