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 > <rc040...@freenet.de>: > > > > 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 - 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 :| -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
