On Mon, 2018-09-24 at 08:47 -0700, Adam Williamson wrote: > If we want to fix that we'd need to somehow run the comps script on all > changes in dist-git and block those changes on introducing comps > problems, which seems like a rather more difficult problem.
Well...thinking about it a bit more, it's just a *different* problem, I guess. We'd need a somewhat different script: it would keep the bit for reading the packagereq entries from comps, but instead of poking dnf repos for current packages, it would have to be able to understand what binary packages the source package in question would produce *before* the change, and what binary packages it would produce *after* the change. That seems easy, but isn't entirely, because you can have stuff like a %ifarch that produces a given subpackage on some arches but others. It's another Will Woods Problem, of rpm specs being able to do an awful lot of stuff that isn't terribly easy to interpret without actually going through the process of building the package. I suppose if we wind up having CI which actually runs a package build for every prospective change to a package, this wouldn't be too difficult, as we could just read out the subpackages...but yeah, I'd say it's kind of a *different* thing, anyway. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
