Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 02, 2022 at 03:35:31PM -0800, Adam Williamson wrote:
> On Sat, 2022-12-03 at 00:14 +0100, Kalev Lember wrote:
> > On Fri, Dec 2, 2022 at 10:30 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx>
> > wrote:
> > 
> > > So there's this CI ticket ATM[0] about whether the environment in which
> > > CI tests are run should or should not include and update from the
> > > 'buildroot' repo, which contains both:
> > > 
> > > 1. Packages that have been pushed stable since the last time a compose
> > > succeeded (for Rawhide that's a Rawhide compose, for Branched it's a
> > > Branched compose, for stable releases it's an updates compose)
> > > 2. Packages that have active buildroot overrides
> > > 
> > > Thinking about this reminded me again why buildroot overrides are such
> > > a bad idea:
> > > https://pagure.io/fedora-ci/general/issue/376#comment-830638
> > > 
> > > Buildroot overrides have unpredictable consequences for builds, updates
> > > *and* tests. I really feel like we should consider disallowing them and
> > > requiring all rebases to be done using side tags. Side tags are a
> > > *much* better design that avoids the problem of packages unexpectedly
> > > being built against a buildroot override somebody else submitted, and
> > > means test systems aren't stuck in a bind of not really knowing for
> > > sure what other packages should be installed when testing any given
> > > package.
> > > 
> > > What does everyone else think? Has the time come? Or is there more we
> > > need to do to make side tags usable for all cases before getting rid of
> > > overrides?
> > > 
> > 
> > I would say that side tags are almost always the correct tool for ABI
> > rebuilds. I imagine people who submit global buildroot overrides to handle
> > a library soname bump are almost always doing it because they haven't
> > learned the "new" ways of doing it.
> > 
> > I'd go as far as to say that anyone who does ABI rebuilds using global
> > buildroot overrides are doing it wrong.
> > 
> > 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.
> > 
> > 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.
> > 
> > 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.
> > 
> > I could continue with the list but I think you get my point that there are
> > some cases where it's useful :) However I'd never use buildroot overrides
> > for soname bump rebuilds; that's what side tags are good for.
> 
> Well, hmm.
> 
> The examples you provide are definitely interesting. They all
> essentially boil down to, well, "I know exactly how this process works
> and I'm gonna take advantage of that to achieve the right outcome
> behind the scenes".

Yeah, those four examples are very good. But they all can be summed up as
"we need this update that is in updates-testing (or possibly will soon be there)
to apply to all subsequent builds". Thus, maybe it would be enough to replace
buildroot overrides with a single switch that says "make this update visible
in the buildroot *now*".

Zbyszek
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux