On Mon, Jul 15, 2024 at 08:23:05AM GMT, Zbigniew Jędrzejewski-Szmek wrote: > 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 I guess you are talking about live images here? If so, they shouldn't need rpm as they don't install using it... or do you mean some other kind of image? > 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).) Somewhat agreed, but moving away from the current setup will be a good bunch of work adding more granularity. > 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. yeah, it would be good to know the scope of this better. Is it all of them? > 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]. That seems like a pretty big hammer, but it should work... > 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… How hard would it be to move back to the old state? Does that mean a bunch of reverts and rebuilds? or ? It sounds to me like there's still a lot of outstanding questions, so I would say moving it to f42 (and trying to land it after branching in rawhide) would be best, but that depends somewhat on how hard the revert is... if it's hard it might be better to power on through? kevin
Attachment:
signature.asc
Description: PGP signature
-- _______________________________________________ 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
