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
