releng

#12943 Track 'release critical packages' similar to critical-path
Opened by adamwill. Modified

Open
Close Issue
  • Describe the issue
    We have the critical path concept and the critpath.py script which records the critical path in a format Bodhi uses. However, the critical path concept is functional and was intended for identifying packages whose updates should get more manual testing. This leaves a fairly large gap: we have no mechanism for identifying what I'd call "release critical packages" or "compose critical packages". I think of this as, approximately, "all the packages in all the release-blocking images and all the packages needed to build the release-blocking images". Over the years we've somewhat stretched the "critical path" concept a bit to cover such packages - for instance, we have the critical-path-compose and critical-path-build groups, which list (some of) the tools needed to build composes and packages respectively - but I kinda don't want to keep stretching it. There are cases where a package is on the Workstation live, for instance, so I think we ought to run appropriate tests to make sure its dependencies don't break, but it's clearly not really part of the "critical path" as we defined that years ago. I feel like, for clarity, we should have a new concept.

I think we should have a mechanism for identifying and recording these packages, similar to critpath.py - it could even be critpath.py, I go back and forth on that. It should definitely produce a similar format for Bodhi to use as an input.

I have two practical reasons for doing this:

  • We could have openQA run appropriate tests on all such packages - run the Workstation tests on all packages in the Workstation live image, for instance, not just all "critical path" packages.
  • We could use it to limit reverse dependency check gating, and thus make it more practical. I've been working towards gating on reverse dependency failures for a while now, but it's complicated by the fact that sometimes an important update breaks a much less important dep that nobody is immediately able (or inclined) to fix. By having this "release critical packages" definition we could make the rule be "an update cannot break the dependencies of any release critical package", which is a more achievable scope, I think.

I've been thinking about and researching this for a while, but I wanted to write it down in a ticket now so the idea's out there and we can prioritize it appropriately.

  • When do you need this? (YYYY/MM/DD)
    No specific date, but I feel like it's kinda important and want to prioritize work on it.

  • When is this no longer needed or useful? (YYYY/MM/DD)
    N/A

  • If we cannot complete your request, what is the impact?
    We will continue to miss things like "oh, this relatively unimportant package on Workstation broke its dependencies and now the compose fails".

Note, the question of how to identify these is an interesting one. You can just resolve out the environment groups in comps, but that does leave some stuff out, I think. Kiwi does have a feature to do a sort of 'dry run' build of a given image and report out all the packages it would install; I was playing around with that a few weeks ago, I ran into a couple of issues but don't entirely remember what they were. Another approach is to parse the logs from the media build tool (Kiwi or whatever) right when a compose finishes.

For the compose tools themselves it's a bit harder, I think we just have to write them down. In theory you could try to sort of scrape them out of the various scripts that actually run builds, but that would probably be so fragile it wouldn't really save any work over writing them down, or be more reliable/accurate.

This a great idea to do; for Kiwi I've also previously given you a script that lists the packages for a profile.

For image-builder you can get the list of comps groups and packages that are to be installed in the buildroot and other pipelines with image-builder describe $imagetype.

We could probably automate running both based on the profiles/image types being built in the pungi configs for a given branch and put them into one comps group?

However, for bootable containers and ostree commits; these are built differently and I am not sure how easily we can get their inputs. For commits we can probably do something based on the yaml files they use as inputs.

If someone wants some help on gathering this set of packages feel free to poke me somewhere (Matrix, e-mail) :)

For both kiwi and image-builder you can also use the rpmlist or sbom outputs to get the solved set of packages though that might be less useful.
Edited by supakeen

Metadata Update from @phsmoura:
- Issue tagged with: medium-gain, medium-trouble, ops

Kiwi I've also previously given you a script that lists the packages for a profile.

Yes, I mentioned this above. I did find at least one problem with it: dnf variable substitutions aren't applied on this Kiwi codepath, so it doesn't actually work with our unmodified templates. You have to edit the relevant repositories file and do the $releasever and $basearch substitutions manually to make it work. I can't remember what the other issue was.

There's no point using comps groups on paths where we can get the package list from a tool, it's an unnecessary intermediate step. The thing that writes out the 'compose critical package' list can just do it directly using whatever tool can produce the list.
Edited by adamwill

and yeah, it might actually be interesting to have pungi do this at compose time if it fits in, I'll have to look at that.
Metadata
None

medium-gain medium-trouble ops

None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.