Dne 04. 12. 22 v 20:27 Zbigniew Jędrzejewski-Szmek napsal(a):
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(a)fedoraproject.org>
>> 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".
It seems that all the mentioned issues are about the (upcoming) stable
releases. But I think Rawhide is different and maybe overrides does not
make a sense there.
Vít
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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