IMO, buildroot overrides are devil, because may have impact on builds performed by other unaware users. The reported examples may be handled by sidetags or requesting exceptions to releng:

Il 03/12/22 00:14, Kalev Lember ha scritto:
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.


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.
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.

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.
Same as above. Broken builds which causes breakage of other dependencies should be removed or the update should be pushed ASAP by Releng.

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