Shells (and DEs!) that set environment from /etc/profile.d will end
up sourcing 20locale.sh from alpine-baselayout. This file will set
`LANG=C.UTF8`, and this will override whatever systemd-localed/systemd
sets LANG to. In other words, locale.conf is effectively ignored. I
hit this issue when debugging why the date in COSMIC was always `M05`
instead of `May`, and why various COSMIC components failed to detect the
locale (because it was set to C.UTF8)
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6535
[ci:skip-build]: already built successfully in CI
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
Installing systemd-resolved by default is still probably not a good
idea (e.g. until #1430 is fixed, at least?), but this adds config for
NM and sd-resolved to get the stub resolver set up automatically when
systemd-resolved is installed manually by a user.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6250
[ci:skip-build]: already built successfully in CI
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/6375
Prepare to add a systemd-stage0 package that will replace the existing
bootstrap logic. First we need to let systemd provide systemd-stage0 and
wait until the new binary packages are built.
In follow-up patches (MR 6440), a systemd-stage0 package will be
introduced (that does not depend on systemd-enabled dbus or polkit). The
systemd/dbus and systemd/polkit will be changed to use
systemd-stage0-dev and systemd-stage0-libs as makedepends. This makes
the following bootstrap work when building without a binary repository:
1. systemd-stage0
2. dbus
3. polkit
4. systemd
If we already have the binary repository, dbus and polkit will be built
against systemd proper as it provides systemd-stage0 packages with this
patch.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6451
[ci:skip-build]: already built successfully in CI
Remove the _shell subpackage that Alpine has from our forked package, as
pmbootstrap currently can't handle it. It tries to build the dependency
gnome-shell for armhf even through this, even though it has !armhf.
A WIP fix for this is in pmbootstrap MR 2592. But let's try to get the
upstream compat check green again first.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6461
[ci:skip-build]: already built successfully in CI
