This way, if one wants to opt-out of resolved, installing a preset
that disables the service is enough. Previously that would only disable
the service, but a dangling symlink would be created.
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.
From time to time there's systemd update with new features which could break an
SELinux enabled system. In order to minimize possible damage on composes we need
to be sure that a system can boot with new systemd and it doesn't generate any
AVC denial.
This test reboots a machine and collects AVC, USER_AVC and SELINUX_ERR audit
messages into avc.log file which is propagated as test artifact.
