It appears that if package A Recommends: B , or B Supplements: A, and A is being pulled into an install tree, this relationship does *not* mean that B will be pulled into the install tree. That means any other artefacts created from that install tree - including at least DVD install media - will also not include B. This leads to inconsistent behaviour. Let's look at a real-world example (thanks kalev): in current F28 at least, gnutls Recommends trousers. However, if we look at a current Server install tree, gnutls is present: https://kojipkgs.fedoraproject.org/compose/branched/Fedora-28-20180418.n.0/compose/Server/x86_64/os/Packages/g/ but trousers is not: https://kojipkgs.fedoraproject.org/compose/branched/Fedora-28-20180418.n.0/compose/Server/x86_64/os/Packages/t/ This is also the case on the Server DVD - if you download https://kojipkgs.fedoraproject.org/compose/branched/Fedora-28-20180418.n.0/compose/Server/x86_64/iso/Fedora-Server-dvd-x86_64-28-20180418.n.0.iso , mount it, and take a look, you will see that it contains gnutls but not trousers. That means that if you do an install from the Server DVD, you get gnutls installed, but you do not get trousers installed. A subsequent 'dnf update' does *not* install trousers. However, if you install from the Server *network install* image (or any network install image in fact), you get both gnutls and trousers - because all network installs have the 'fedora' repository, which is backed by the Everything install tree, as their default. Of course, if you installed without gnutls and then did 'dnf install gnutls', you'd get both gnutls and trousers (well...this is in fact impossible as dnf requires gnutls, but *in theory* that's what would happen). This inconsistency is clearly not desirable. This also affects our *ostrees*. We can prove this by comparing Atomic Host and Atomic Workstation - 'ostree-3' and 'ostree-4' in our reference compose. As we can see here: https://kojipkgs.fedoraproject.org/compose/branched/Fedora-28-20180418.n.0/work/ostree-3/extra_config.json ostree-3 (that's FAH) uses the Everything tree for its base repo, but as we can see here: https://kojipkgs.fedoraproject.org/compose/branched/Fedora-28-20180418.n.0/work/ostree-4/extra_config.json ostree-4 (that's FAW) uses the Workstation tree for its base repo. Now, let's look at the logs of their actual ostree composes: https://kojipkgs.fedoraproject.org/compose/branched/Fedora-28-20180418.n.0/logs/x86_64/AtomicHost/ostree-3/runroot.log https://kojipkgs.fedoraproject.org/compose/branched/Fedora-28-20180418.n.0/logs/x86_64/AtomicWorkstation/ostree-4/runroot.log Just search for 'gnutls' and 'trousers' in both. 'gnutls' is shown being included in *both*, but 'trousers' only appears in ostree-3/FAH, not ostree-4/FAW. So it seems clear that rpm-ostree *does* pull in weak dependencies when they're available (or else trousers wouldn't be in FAH), but when they *aren't* available, it skips them (which is correct behaviour). This is very likely why mesa-libEGL went missing from FAW in the 20180417.n.0 compose, breaking GNOME: https://bugzilla.redhat.com/show_bug.cgi?id=1568627 . An update was pushed stable right before that compose - https://bodhi.fedoraproject.org/updates/FEDORA-2018-af5c146d50 - which changed libglvnd from Requiring mesa-libGL and mesa-libEGL to Recommending them. Because of this bug, that meant they were no longer included in the Workstation install root, and hence they could not be pulled into the FAW ostree.
For the record, live media *do* pull in Recommends...at least, the 20180417.n.0 Workstation live image wasn't missing mesa-libEGL.
So the questions I have are: * Add a flag for this? * Default to on? off? * How much bigger does this make the boot.iso?
So to be clear, I'm not suggesting we want these packages *in the installer environment*, necessarily. I'm concerned specifically about what's in *the install trees*. Given that, it seems it may actually be Pungi, not Lorax, which decides what packages go into which install trees. Apparently Lorax only creates the installer environment or something. So, re-assigning tentatively to Pungi.
Proposing this for an F28 Final freeze exception, as it affects what's included in ostrees and the Server DVD.
When Pungi runs lorax, it gives it a repository with all packages, so that can resolve weak dependencies without issues. There is a plan to use the same repo for ostree creation, but that does not work due yet. Pungi itself does not currently work with weak deps at all. It's quite straightforward to add handling Recommends the same as Requires. Adding Supplements is a little more involved, but also doable. PR: https://pagure.io/pungi/pull-request/917
"When Pungi runs lorax, it gives it a repository with all packages, so that can resolve weak dependencies without issues. There is a plan to use the same repo for ostree creation, but that does not work due yet." Yes, the Everything repo...but even if we use Everything as the base repo for all ostree composes, this still leaves us with the issue of the Server DVD, which we obviously can't build from the Everything repo. The Server DVD is basically just the Server netinst plus the whole Server install tree dumped onto a DVD ISO image, AIUI. Thanks for the PR. I'd like to be sure about the impact of this change. So far as you're aware, would this affect anything *besides* the install trees and the deliverables we currently know are indirectly affected by this via the contents of the install trees (ostrees and DVD installer images)? Could it somehow cause Recommended packages to be pulled into minimal cloud or appliance images, or anything like that? Thanks!
Discussed at 2018-04-23 freeze exception review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2018-04-23/f28-blocker-review.2018-04-23-16.00.html . We agreed we want to gather more information about the possible consequences of this change before deciding whether to grant an FE, including trying to figure out the whole set of Recommends: and Supplements: that actually exists in Fedora 28 at present.
Created attachment 1426612 [details] Diff of packages in compose with weak deps enabled I re-ran gathering for Fedora-Rawhide-20180423.n.0 with weak deps enabled. Attached is a list of added packages for each variant and architecture. In Everything there are a few multilib packages on x86_64. For Server and Workstation there is a lot more additions. Can someone eyeball it and decide if this is what is requested?
Thanks a lot for the diff. I'll look through it in detail, but some that we hadn't previously noticed jump out at me right away, like `oci-register-machine` in Server. That's because of this block in the docker spec: %if 0%{?fedora} || 0%{?rhel} > 7 Recommends: oci-register-machine Recommends: oci-systemd-hook Recommends: criu %else Requires: oci-register-machine Requires: oci-systemd-hook Requires: criu %endif so if you install the Server DVD with a package set that includes docker, you won't get those packages...which is probably not what we want. Here's another one which looks significant. hardlink, kpartx and pigz are in the Server and Workstation diffs because of dracut: %if 0%{?fedora} > 22 || 0%{?rhel} > 7 Recommends: grubby Recommends: hardlink Recommends: pigz Recommends: kpartx %else Requires: hardlink Requires: gzip Requires: kpartx %endif I think this means initramfs'es generated from Server DVD installs and FAW installs won't be hardlinked, unless the user subsequently explicitly installs the 'hardlink' package or it gets pulled in via some other dependency chain. As for kpartx, dracut appears to use it in relation to dmraid sets; it's *possible* that firmware RAID support on Server and FAW installs would be affected by this. I don't think pigz would be a big issue as gzip is likely included and dracut will I think just fall back from pigz to gzip. Those are just the ones that happened to jump out at me immediately, working out all of these would take a while. Thanks again for the data.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I don't think this got magically fixed at any time.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I believe this is still an issue, and in fact I think it bit us once during the F33 cycle, though I forget the details.
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
Bit us again this cycle: https://bugzilla.redhat.com/show_bug.cgi?id=1951062
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.
This is still the case, though I *think* these days it only affects the Server DVD case - Server is the only install tree apart from Everything that actually has a repo these days. You can confirm this with the dracut -> hardlink case: the Server repo for current Rawhide composes contains dracut - see https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20221104.n.0/compose/Server/x86_64/os/Packages/d/ - but does not contain hardlink - see https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20221104.n.0/compose/Server/x86_64/os/Packages/h/ .
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.
Still the same in current Rawhide: https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20230803.n.0/compose/Server/x86_64/os/Packages/h/
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.