On 03. 12. 22 0:14, Kalev Lember wrote:
On Fri, Dec 2, 2022 at 10:30 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx
<mailto: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
<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.
Maybe doing occasional blog posts and teaching maintainers how to do multi
package updates would be helpful? Not sure what else we could do to help
improve the situation here.
I am pretty much with Kalev on this.
The only way to land ABI (or similar) rebuilds should be side tags, but I still
use overrides for other stuff.
E.g. when I need a change in an RPM macro package to make other packages build
properly. I see no reason for creating a single bodhi update with the RPM macro
package and couple packages that were blocked on that update.
My latest buidlroot overrides were:
https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-8-34
See
https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/54#comment-121866
https://bodhi.fedoraproject.org/overrides/python-setuptools-59.6.0-3.fc36
https://bodhi.fedoraproject.org/overrides/python-pip-21.3.1-4.fc36
https://bodhi.fedoraproject.org/overrides/python-rpm-macros-3.11-5.fc37
To workaround https://pagure.io/fedora-ci/general/issue/240
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
