There are rpms which have files in /usr/bin which would trigger the
condition in the generator, even when building on an unmerged system,
and the package would have Requires:filesystem(unmerged-sbin-symlinks).
The corresponding Provides is actually only generated when filesystem
itself is built with the merge, so effectively the package with the
Requires would become uninstallable.
The generator will generate a Requires on filesystem(unmerged-sbin-symlinks),
i.e. effectively on a new-enough version of _this_ package. This is needed to
solve the following problem:
as packages are rebuilt in a merged-sbin environment, their payload paths
change from /usr/sbin to /usr/bin. In all the cases where there were other
packages that dependended on the old paths via explicit Requires, compat
Provides on the old path was added along with
Requires:filesystem(unmerged-sbin-symlinks). This means that those packages
will not be installed with an older filesystem.rpm. But for packages that
didn't need this special treatment, no dependency is generated. When they
are installed into an upgraded environment which still has split-sbin and
has an older copy of filesystem, the file is moved without the compat
symlink being created. Thus, any scripts, or systemd service files, etc.,
referring to the old path are now broken. We need to require a new-enough
filesystem.rpm to be installed so avoid breakage on such partially upgraded
systems.
This is borne out of the discussion in
https://gitlab.com/fedora/bootc/tracker/-/issues/29. The general
idea is that the ostree builds would set up the fs structure properly
but need a clear indicator of what is desired. This is better than
hardcoding a version comparison.
%bcond merged_sbin is added, with a default of 0.
With the default state, the spec file should behave identically to the version
before any changes related to the sbin merge we started. (In the pretrans
scriptlet, the order of mkdirs is different, but that shouldn't matter.)
This time, I used "dnf5 repoquery -l '*' | grep '/sbin'" to generate the list
of names. I hope the list is complete now. The list is sorted using
"sorted(…, key=lambda x: x.lower())" in Python.
When packages are rebuilt in a merged buildroot and their contents migrate
from /usr/sbin to /usr/bin, we want to provide compat symlinks so that the old
names still work.
This scriptlet covers all packages that have files in /usr/sbin in F40. We
have just one scriptlet in filesystem because that's easier than having
separate scriptlets in each package.
When the package for which we created a symlink is removed, we remove the
symlink.
The list of filenames was initially created using 'dnf repoquery', but it
seems that this is unreliable. Additional files were generated using:
(ls -1 /usr/sbin/|sort -g|sed 's/.*/ "\0",/'; sed -n -e '/^ "acme/,/^ "zramctl"/p' <filesystem.spec)|sort|uniq|xsel
We need to also trigger on /sbin, because some packages have files in /sbin
(not just /usr/sbin). In particular, this affects glibc, which (still) has
/sbin/ldconfig.
https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
/usr/sbin is now created via a scriptlet. In a pristine installation, we'll end
up with merged sbin. On upgrades, symlink creation will fail and the existing
/usr/sbin directory will remain.
The updated package means that if we build packages, they'll see merged sbin in
the filesystem. If additionally rpm defines %{_sbindir} as /usr/sbin, those
packages will get files in the merged location. A separate pull request will be
filed for rpm.
For building rpms, the change in rpm is more important, because what really
matters is the path specified in %files, so even if the buildroot has
merged-sbin, if %_sbindir says otherwise, package will use the unmerged path.
For installation on disk, the change here is more important, because even if
packages specify unmerged paths, if the directory on disk is a symlink, that
symlink will be followed, so the installation will end up with merged sbin.
We want to build packages in a chroot where /usr/sbin is a symlink to /usr/bin,
so that packages get files in the merged location. But on user systems,
especially when the transition is in progress, we will have packages with files
in /usr/sbin, so we accept that /usr/sbin in a separate directory.
On RISCV we typically expect to have /usr/lib64/<ABI> directory. Some
software is strict about it, and some actually fallback to /usr/lib64.
We only support a single ABI, that's lp64d. We have it as a symlink back
to the parent. That means /usr/lib64 and /usr/lib64/lpd64 both point to
the same content.
Signed-off-by: David Abdurachmanov <davidlt@rivosinc.com>
Filesystem has a dependency on /bin/sh (#1306489)
Add /usr/share/X11/fonts/ to default filesystem (#2107447)
Remove obsolete and forbidden Group tag
Own zsh and fish completions directories (rhbz#1312594)
Improve directory creation to avoid 'Argument list too long' error
Many packages needs to put single *.service file or similar into those
directories, but otherwise does not need to depend on systemd. It would
leave those directories unowned. Avoid owning that directories by every
package.
When working in rootless container environment with user namespaces,
those directories are pre-populated by the container runtime as
bind-mounts from host.
Such bind-mounts though naturally inherit ownership/permissions from the
host's filesystem.rpm, and non-privileged "root" inside container can
not be allowed to touch files owned by host's UID=0. Those directories
are then shown as owned by 'nobody:nobody'.
When filesystem.rpm holds those /proc and /sys in payload, rpm tries to
re-chown the file to root:root on every package update transaction.
This operation can not succeed because 'root:root' inside container maps
to some large UID/GID on host -- and so the RPM transaction fails.
As a workaround (there's no better way currently), remove /proc and /sys
from the packaged payload, mark those directories %ghost and create them
by scriptlet.
Resolves: rhbz#1548403
Version: 3.14-4
