Bug 1569242 - Weak dependencies (Recommends, Supplements) not included in install trees, hence DVD media, ostrees
Summary: Weak dependencies (Recommends, Supplements) not included in install trees, he...
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: pungi
Version: 34
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Lubomír Sedlář
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F28FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2018-04-18 21:03 UTC by Adam Williamson
Modified: 2021-04-19 16:57 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)
Diff of packages in compose with weak deps enabled (1.50 MB, application/x-tar)
2018-04-25 12:11 UTC, Lubomír Sedlář
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1568627 0 unspecified CLOSED GNOME crashes on boot after install of FAW in Fedora-28-20180417.n.0 : "Missing extension for GBM renderer: EGL_KHR_plat... 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1568881 0 unspecified CLOSED Missing dependency on mesa-dri-drivers 2021-02-22 00:41:40 UTC

Internal Links: 1568627 1568881

Description Adam Williamson 2018-04-18 21:03:57 UTC
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.

Comment 1 Adam Williamson 2018-04-18 21:05:32 UTC
For the record, live media *do* pull in Recommends...at least, the 20180417.n.0 Workstation live image wasn't missing mesa-libEGL.

Comment 2 Brian Lane 2018-04-18 21:19:47 UTC
So the questions I have are:

* Add a flag for this?
* Default to on? off?
* How much bigger does this make the boot.iso?

Comment 3 Adam Williamson 2018-04-18 21:30:06 UTC
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.

Comment 4 Adam Williamson 2018-04-18 22:02:14 UTC
Proposing this for an F28 Final freeze exception, as it affects what's included in ostrees and the Server DVD.

Comment 5 Lubomír Sedlář 2018-04-19 07:34:21 UTC
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

Comment 6 Adam Williamson 2018-04-24 01:13:43 UTC
"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!

Comment 7 Adam Williamson 2018-04-24 01:14:42 UTC
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.

Comment 8 Lubomír Sedlář 2018-04-25 12:11:15 UTC
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?

Comment 9 Adam Williamson 2018-04-25 15:46:36 UTC
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.

Comment 10 Ben Cotton 2019-05-02 21:54:07 UTC
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.

Comment 11 Adam Williamson 2019-05-21 21:51:44 UTC
I don't think this got magically fixed at any time.

Comment 12 Ben Cotton 2019-08-13 19:18:34 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

Comment 13 Ben Cotton 2020-11-03 17:00:38 UTC
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.

Comment 14 Adam Williamson 2020-11-03 20:56:14 UTC
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.

Comment 15 Ben Cotton 2021-02-09 16:14:47 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Comment 16 Adam Williamson 2021-04-19 15:57:14 UTC
Bit us again this cycle:
https://bugzilla.redhat.com/show_bug.cgi?id=1951062


Note You need to log in before you can comment on or make changes to this bug.