Hi!
I've been trying to implement the sbin-merge for F41 [1].
Side tag f41-build-side-92231 was created and about 80 packages were
rebuilt there. This is enough to implement the merge on "normal" end-user
systems and in buildroots for packages in mock and koji.
The current status is that the pending bodhi update [2] from the side tag is
blocked on failing tests. The tests in the CI caught a number of issues:
1. Installability tests (*.functional) are generally busted and can
be ignored. I wrote a mail about that yesterday [3].
2. Images built with lorax are missing a bunch of executables. It turns out
that lorax templates filter executables by path, so we end up with images
that don't have /usr/bin/losetup, /usr/bin/mkswap, but OTOH have various
binaries that were supposed to be removed but are now in /usr/bin.
[3] should fix the issue. This is a fairly simple change, so I imagine it
_could_ be merged and pushed out quickly.
(I'll note on the side here that that filtering seems to be generally
busted. In the image I looked at, the rpm database was present, as was the
dnf installation, but /usr/bin/rpm was not. That doesn't make any sense,
since the rpmdb is not really useful without rpm, and dnf won't do anything
without rpm either. And this is all not related to the sbin merge, since
/usr/bin/rpm and /usr/bin/dnf haven't moved… IMO, the approach taken by
mkosi-initrd, i.e. using packages to build the image, and fixing packaging
to be more granural in cases where we need more granularity is a better
approach. Filtering paths by glob will always be ineffective (because the
binary is removed, but not everything else it pulled in), fragile (because
binaries move, gain and lose dependencies, or new binaries are added),
wasteful (because we need to reimplement similar filtering in multiple
places (lorax, dracut, container builds, custom images), and inefficient to
implement or change (the template is embedded in code).)
3. rpm-ostree builds are broken because they create the basic filesystem
setup in a custom way, not using filesystem.rpm, so we end up with neither
the compat symlink from /usr/sbin→bin nor the individual compat symlinks
/usr/sbin/*→../bin/* when individual packages that were rebuilt in the new
worldview are used to build ostree images [4,5].
I don't have a good understanding of the extent of this bug (i.e. if
all or only some images are affected) and how hard it'll be fix.
As a partial workaround, I've been submitting pull requests to remove
full paths from scriptlets. This helps with the ostree images, but is
the is the right thing to do in any case [6,7]. With this, the ostree
images would be good enough to pass CI, but it's not a full solution.
4. The tests install a mix of old and new packages, and uncovered the
following failure mode:
package A with files in sbin is rebuilt with merged-sbin, but no other
package has Requires on paths in package A, so we didn't need to add
compat Provides to A, so it doesn't have any Requires on the new
filesystem package, so rpm will happilly install it on a system with old
filesystem rpm. The compat symlinks are not created. Rpms work, but
scripts that call the old path with /usr/sbin will fail. To hit this, one
has to do partial upgrade, but of course this is supported and must work.
To avoid this, I want to add a rpm fileattr generator that will generate
'Requires: filesystem(unmerged-sbin-symlinks)' for packages which have files
in /usr/bin that previously were in /usr/sbin, meaning that those packages
when rebuilt in the new worldview will require an updated filesystem.rpm
to be installed too. There's hundreds of such packages, so having one
generator is nicer than adding the requirement explicilty to individual
packages.
The generator would be added to filesystem subpackage [8] that would be
pulled in via redhat-rpm-config [9].
So… the question now: should I pull the plug on the change for F41,
dump the side tag, and try again for F42? Or wait for some of the patches
above to be merged? The mass rebuild is supposed to start in two days…
Zbyszek
[1] https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
[2] https://bodhi.fedoraproject.org/updates/FEDORA-2024-3aafcac6a8
https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/XW2YGOMR5UAXV2CHWOJWGPNLWDRRNO43/
[3] https://github.com/weldr/lorax/pull/1409
[4] https://github.com/coreos/fedora-coreos-tracker/issues/1714#issuecomment-2223100778
[5] https://gitlab.com/fedora/bootc/tracker/-/issues/29
[6] https://src.fedoraproject.org/rpms/selinux-policy/pull-request/448
[7] https://src.fedoraproject.org/rpms/cifs-utils/c/934e038df9023177535e7cda564624ce773f0f0a
[8] https://src.fedoraproject.org/rpms/filesystem/pull-request/15
[9] https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/308
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
