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
Il 03/12/22 00:14, Kalev Lember ha scritto:
However, having said that, I also find buildroot overrides useful.
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
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".