The same patch is already used on 3 devices, to make it shared.
WARNING: vmlinux.o(.devinit.text+0x1bd4): Section mismatch in reference from the function msm_pm_boot_probe() to the function .init.text:msm_pm_boot_init()
ERROR: postmarketos-base-downstream-disable-udev-v4l-2-r1: trying to overwrite usr/lib/udev/rules.d/60-persistent-v4l.rules owned by systemd-udevd-257.5-r0.
The APKBUILD reference seems to suggest that versioned provides= can
have any valid version string (e.g. 0.12-r3) in the `provides=` var, and
that it doesn't have to match `$pkgver-r$pkgrel` for the APKBUILD. IIRC
this test intends to catch typos like `provides=foo=$pkgver-$pkgrel`, so
this makes it pass when any valid version string is given.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6475
[ci:skip-build]: already built successfully in CI
alpine-base directly depends on openrc. We have had different[1]
conversations[2] with upstream. And the main conclussion[3] has been:
if you want to do something different, just depend on things
yourself. This is indeed what docker images do. So let's just get the
things that we want from alpine base (quite some!), and ignore what we
don't want (openrc, busybox openrc and init packages). Up until commit
12d125ab8b72f0249fd6aae000170a4fa78a83ab in pmbootstrap every
postmarketOS installation would have alpine-base in
/etc/apk/world. Therefore, we add a versioned provides to
postmarketos-base with a very high version, which conflicts with the
upstream version but should be chosen instead.
alpine-conf is now a dependency of postmarketos-base-openrc, since it
dependes on openrc for calling setup-*
scripts. postmarketos-base-systemd already implements those needed.
Contrary to the first attempt[4], I have kept the dependency on
alpine-release. Changes to that are independent to the usr-merge, and
can be done as a follow-up.
This should allow to drop the fork of alpine-base currently in the
systemd-extra repository!
To this day, every single pmOS installation will have alpine-base in
the world file, which means that systemd installs will the forked
package until users specifically run "apk del alpine-base". We must
add this to release notes and to an edge blog post. Alternatively we
could have an empty package with a very high version providing
alpine-base. This also means that to get installs to work, we need a
pmbootstrap release with[5] on it.
[1] https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63935
[2] https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/71686
[3] https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/71686#note_435428
[4] https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/5026
[5] https://gitlab.postmarketos.org/postmarketOS/pmbootstrap/-/merge_requests/2580Fixes#2806
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6475
Why is this needed?
To be able to test the usr-merge downstream we need to stop
depending on alpine-baselayout. For that, we need to stop depending on
alpine-base. This is a first step to create a "provides" solution
downstream between openrc and systemd systems, so that in a follow-up
commit we can recreate alpine-base downstream without the hard-coded
openrc dependency. The virtual instead of a versioned dependency means
that:
* In theory systemd and openrc could be installed in parallel. In
practice we avoid that with !openrc in the systemd package and
!systemd in the postmarketos-base-openrc one. There is a lot more
work required with provides (both upstream and downstream) regarding
things like elogind and eudev to be able to even have them
package-wise ready to be installed in parallel
* There must always be one installed. Here we have 3 scenarios:
* pmbootstrap install where pmbootstrap will decide which one
* update from existing install. The virtual makes sure that APK
won't remove the local package because versions changed
* Manual APK work, where the provider_priority or the user will
choose
How does this work? Hypothesis:
* openrc upgrades: the postmarketos-base-openrc remains installed,
moves from being an "install_if", to be there because it fulfills
the postmarketos-base-init requirements.
* systemd upgrades: postmarketos-base-systemd is still in
/etc/apk/world, and it fulfills the new dependency in
postmarketos-base. Nothing happens.
* openrc installs: pmbootstrap will choose one of
postmarketos-base-openrc and postmarketos-base-systemd... But which?
The one with the higher version?
* systemd installs: postmarketos-base-systemd is installed before
anything else is. That means, postmarketos-base-init will already
be satisfied when postmarketos-base gets installed, and openrc will
not be installed
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6475
Luca Weiss