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
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
