However, having said that, I also find buildroot overrides useful. Some examples:
1) Fedora is in freeze. GNOME has gotten a Freeze Exception to pull a new version through the freeze, but that includes a library soname bump.
What I would do in that case is submit the GNOME megaupdate to Bodhi, and also submit the library as a buildroot override to ensure that nothing can build against the old soname -- I am fairly confident that the GNOME megaupdate, together with the soname bump makes it to stable first.
The premise here is that a library got a soname bump. That means that the megaupdate should include all packages which depends on that library.
Say, in the megaupdate there's foo-1.0.0-1 which was built
against libbar.so.2. If any other user makes a build of
foo-1.0.0-2 against the old libbar.so.1, we can have Bodhi stop
the user when they try to create the update, since there's already
a pending multiple update containing foo. After the megaupdate is
pushed to stable, if the user tries to push again foo-1.0.0-2, QA
tests should see it depends on the old soname and again block the
update.
If the CVE fix is so urgent, it doesn't make sense to push it out only for container. We should have a policy for asking Releng exemptions about the testing period and push the update out for everything.
2) I need to do a container build and include a new CVE fix (as it's critical and we need to get fixes out ASAP), but that package build to include in the container is only in updates-testing.
What I'd do in this case is to submit a buildroot override because everything that's overridden gets included in container builds. After my container build is done I'd expire the buildroot override.
Same as above. Broken builds which causes breakage of other dependencies should be removed or the update should be pushed ASAP by Releng.
3) We've had some "fun" issues with sysprof symbols leaking out from the GTK stack into other libraries consuming it. This has caused subtle ABI issues and when working on a fix and to make sure no package can build against the "wrong" GTK version, I've used buildroot overrides.
4) Compiler issues, with compilers producing broken code.
To test the fixes and make sure packages start using the new fixed versions ASAP, a buildroot override is often useful.
Same as above.
The purpose we have an update system is to avoid not only distribution breakages for end users, but also buildroot breakages. Buildroot overrides just overrides everything, so I think they must be a Releng right only.
Or let's just get rid of Bodhi and trust all packagers to "know
exactly what they are doing with their package".
Mattia
_______________________________________________ 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
