Dne 01. 03. 24 v 19:58 Adam Williamson napsal(a):
On Fri, 2024-03-01 at 09:34 +0100, Michael J Gruber wrote:Am Fr., 1. März 2024 um 07:55 Uhr schrieb Ralf Corsépius <rc040203@xxxxxxxxxx>:Hi, I intend to update gumbo-parser to 0.12.1 in rawhide. This comes along with an soname bump libgumbo to libgumbo.so.2 This requires a rebuilt of several dependent packages, AFAICT: claws-mail litehtml mupdf perl-HTML-Gumbo python3-PyMuPDF qpdfview zathura-pdf-mupdf I'll try to rebuild these packages on side-tag f41-build-side-84865 (Please, bear with me, I haven't used side-tags, before. I couldn't find any usable docs on how to use them) Preliminary tests indicate, something unrelated to libgumbo.so.* has changed with these packages (Probably mupdf), causing gpdfview to FTBFS and dependency changes in rawhide.Interesting. I wasn't aware of that dependency - I guess I have to re-run detection more often. Speaking of - do we have a policy about this? This is not about blaming, but how do we ensure that everyone is aware of new dependencies? Frequent re-runs to detect them or announcements the other way round?Unless I've missed something, the general situation in Fedora is all the onus is on the party bumping the depended-upon package. We don't require dependent packages to announce their dependencies in any way (except, you know, through an actual package dependency). If you're changing a package in any way that could be fairly considered "not backwards compatible" for another package depending on it in a "typical" way, I'm pretty sure the onus is on you to find those dependencies and make sure they are handled, not vice versa. Honestly, we could really use more automation here, but it's a fairly hard thing to do *reliably* and there just isn't anybody specifically tasked with it so it doesn't happen. I had an interesting chat with Martin Pitt about britney - https://release.debian.org/doc/britney/what-is-britney.html
We have: https://gitlab.com/fedora/packager-tools/mass-prebuildIt does not do automated official builds, but it certainly helps to better understand what is the impact of changes on dependent packages.
Vít
- which
Debian and Ubuntu use in this area. If I understood the explanation
correctly, it's a sort of automated update bundler; Debian and Ubuntu
devs can just throw builds at a staging area, and britney takes care of
grouping them into logical sets based on their dependencies. So to do
an soname bump you'd build the bumped library in the staging area, wait
for it to appear in the staging area buildroot (I guess), then build
all the dependencies, and britney would figure out that this group of
packages needs to go out of the staging area and into stable together
and make that happen, so the packager doesn't have to group them
manually. If you've got a build in the staging area which britney can't
"solve", I think, you get alerts so you know what needs doing ("package
X needs rebuilding against your thing", or whatever).
Something along those lines for Fedora would be awesome! But we can't
just lift-and-shift britney - we'd have to adapt it to RPM dependencies
(if that hasn't been done already) and integrate it with Bodhi
(definitely not done already). That's a lot of work for someone. We
could conceivably code an equivalent feature into Bodhi ourselves, but
again, a lot of work for someone. And it'd probably need some thought
about a way to allow cutoffs/exceptions so you could get an soname bump
through if it has 500 dependencies and you've fixed 499 and the other
is some obscure package that hasn't been maintained for a year. All of
that is work that isn't #1 on anybody's priority list, I think :( I
would love to say I'm gonna work on it, but I've added three neat
projects to my "neat side project backlog" since *yesterday* and it's
about a thousand items long at this point, so, hmm.
It'd also be nice to have a reliable distro-wide automated check for
"does this update break the dependencies of anything else?" so we could
at least prevent all updates that break dep chains going stable. Right
now openQA catches some such cases, but *only* ones that affect
critical path packages *and* happen to involve a package that actually
gets installed during an openQA test. The CI rpmdeplint test is
supposed to cover this, I think, but historically hasn't proven
reliable enough to be made universally gating (and I think maybe only
works on Rawhide). But again...somebody has to clear the time to work
on it :|
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ 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
