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". Which, you know, we have a lot of stuff like that, but it can be difficult to work with in ways like this. I do see the value in your use of the buildroot in those cases, but I can't help thinking there must be a *better* way. But, I'm not sure I've thought of a practical one yet. All the ones that came off the top of my head turn out to be silly after thirty seconds thinking about it. Ugh. Hum. I suppose if there really were only uses of the buildroot like the above...then...it should be *fairly* safe for test systems to always test against the buildroot repo contents. Uh. Maybe. I don't love it, but I don't know what's better. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net _______________________________________________ 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
