On Wed, Apr 22, 2020 at 10:55 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > On 22. 04. 20 10:25, Susi Lehtola wrote: > > Hello, > > > > > > first, I'm sorry for a partial screw-up of the libxc soname bump announcement. > > It appears I am not alone: there are a few soname bumps each month, many of them > > still unannounced. Hi! I'm sorry about first claiming the libxc soname bump was unannounced, I corrected that in a follow-up email. I had seen lots of broken dependencies on the old library version in fedora-health-check, and when I looked none of the dependent packages had been rebuilt - which is why I assumed the bump was unannounced. > I'd guess the biggest problem is that a lot of packages have soname bumps hidden > by * globs. I.e. the maintainers update thei package without even realizing > they've bumped. > > This is getting better and better now, as more packages follow the rule not to > do this and use a more strict glob. I agree, this at least helps to make it not happen accidentally. For most new packages, this rule is now enforced by reviewers, so things are starting to get better :) > > This raises the question: shouldn't there be some sort of automatic tool for > > making soname bump announcements? It seems to me that this is a thing where > > computers easily beat humans: query for dependent packages, and shoot their > > maintainers an email. Maybe something that could go in fedpkg? Whenever changed > > sonames are detected, hold the update aside and start ringing the alarm bells? > > If somebody does this, note that there are basically 3 steps here: > > 1. > > $ repoquery --repo=rawhide --source --whatrequires 'libfoo.so.1.0()(64bit)' > > 2. > > https://pagure.io/fedora-misc-package-utilities/blob/master/f/find-package-maintainers > > 3. > > Write and send e-mail. > > > However, do you propose that this would happen automagically when the soname is > bumped? What if I am already in touch with the dependent package owners? I'm not sure how that could be automated, in particular the "one week in advance" aspect of the current Update Policy for soname bumps in rawhide. Some rebuilds for soname bumps might be "just fine", while others will require coordination with the owners of dependent packages (possibly due to API changes). It's impossible for any automation to figure out if an soname bump falls into the first or into the second category, so some amount of human intervention will probably always be necessary. However: I still think we could do better, and at least provide some scripts to automate the things that are possible to be automated, for example: - querying repositories for: "which packages depend on this version of the shared libraries in this package" - filling out an email template for: "hello, soname bump in libbar incoming in a week", with fooz-maintainers@xxxxxx of dependent foo packages in CC > IMHO better automation would be to gate stuff at reverse rpmdeplint: > > https://pagure.io/fedora-ci/general/issue/46 > > There are 2 problems with that: > > - such check in the CI does not exist yet > - gating is still opt-in > > See also: > > https://pagure.io/fesco/issue/2343 Yup, that's what I originally proposed to do ... but with taskotron being decomissioned (the machine it runs on won't be moved to the new datacenter, IIRC), that won't work. Gating updates for soname bumps should not be too hard to a thing to do (you only need to query RPM Provides before and after, and compare provides for shared libraries), and it would at least make sure nothing gets pushed without human interaction. Maybe that check could be integrated into rpminspect? Even writing a standalone check should not be that difficult (querying RPM provides and comparing strings). Fabio > -- > 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 _______________________________________________ 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
