I'm not entirely sure if this is the right form...
Is Conflicts? useful when we have Obsoletes?
Seem to work OK. I tested:
dnf --installroot=... install x86_64/systemd-standalone-sysusers-246.6-2.fc34.x86_64.rpm x86_64/systemd-standalone-tmpfiles-246.6-2.fc34.x86_64.rpm
→ succeeds with a new installation
→ fails if the installroot already had systemd installed
dnf --installroot=... install x86_64/systemd{,-libs,-pam}-246.6-2.fc34.x86_64.rpm noarch/systemd-noarch-246.6-2.fc34.noarch.rpm
→ uninstalls the two standalone packages
These packages include binaries that link to a static version of
libsystemd-shared, so they don't depend on the systemd-libs package at
runtime.
These packages are intended to expose systemd-tmpfiles and systemd-sysusers
to non-systemd systems, such as container images.
Note that static linking only pulls in the small subset of functions from
libsystemd-shared that are actually used by the binaries, so the total size of
a statically linked binary is much smaller than the sum of the shared binary
with the shared library. The resulting binaries on an x86_64 build have 272KB
(tmpfiles) and 180KB (sysusers).
This commit relies on the -Dstandalone-binaries=true build configuration that
was pushed upstream in PR 16061 and released in systemd v246.
We need to disable it by default in resolved so that it doesn't fight
with avahi for the port when both are started up in parallel.
I also moved nss-files before nss-resolve. This is unfortunate because
resolved cached files and with the move, the file will be re-read on each
query. Nevertheless, we want nss-files to have higher priority than nss-mdns
to honour local config. Fortunately, only some people put lots of entries
in /etc/hosts, so the inefficiency incurred by this isn't important for
most users.
nss-myhostname is moved after nss-files, following the change in
upstream recommendations.
error: line 639: Trigger fired by the same package is already defined in spec file: %post libs
It's not clear what rpm is complaining about here, but the two %triggerun's
for the same package seem to be the most likely offender.
I wanted to avoid applying to preset reset twice, alas.
The default line is
> hosts: files dns myhostname
Some people might insert mymachines, most likely as:
> hosts: mymachines files dns myhostname
The scriptlet for nss-mdns inserts mdns before dns:
> hosts: ... files mdns4_minimal [NOTFOUND=return] dns ...
The scriptlet replaces 'files dns myhostname' with
> resolve [!UNAVAIL=return] myhostname files dns
This follows the upstream recommendation. myhostname is ordered earlier
because
a) it's more trustworthy than files or especially dns
b) resolve synthetizes the same answers as myhostname, so it doesn't
make much sense to have myhostname at any other place than directly
after resolve, so that if resolve is not available, we get answers for
the names that myhostname is able to synthesize with the same priority.
See https://fedoraproject.org/wiki/Changes/systemd-resolved.
The acl package is not present in the buildroots when building
in bootstrap mode, but test-acl-util needs /usr/bin/getfacl.
Thus it should be an explicit build-time dependency.
Also only execute the fallback when we're upgrading the RPM package.
Add a comment to indicate the actual bug in systemd v239 we're trying to
fix with this fallback.
Tested: Upgraded from v239 on a machine and confirmed that running
`sudo systemctl status` was working as expected after the upgrade, rather
than failing with "Access denied."
This might be more reliable when upgrading from an older systemd package. The
systemctl call to reexec will occasionally fail with "Access denied" when we
upgrade from a much older version (like 2-3 versions older). However, sending
PID 1 a SIGTERM is documented to be mostly the same and fixes it 100% of the
times.
Signed-off-by: Anita Zhang <the.anitazha@gmail.com>
Signed-off-by: Filipe Brandenburger <filbranden@gmail.com>
0002-Revert-units-set-NoNewPrivileges-for-all-long-runnin.patch was added exactly
a year ago because selinux policy needed to be updated. I think we can drop the
patch now.
Also drop part of 0998-resolved-create-etc-resolv.conf-symlink-at-runtime.patch:
the service runs as unprivileged user, so the creation cannot succeed. The other
part of the patch is kept.
systemd package numbering is completely different than
u2f-hidraw-policy, so I'm using a fixed number. "-40" is supposed to
be sufficiently high so that we stay higher and preserve the upgrade
path even if the package is updated in older releases.
