Re: Automatic check for bodhi updates not to break RPM dependencies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2023-11-07 at 15:20 +0100, Miro Hrončok wrote:
> On 07. 11. 23 12:17, Sandro Mani wrote:
> > Hi
> > 
> > Due to an unfortunate oversight of an incorrect branch merge a couple of months 
> > ago, a recently backported security fix caused an unwanted gdal soname bump in 
> > F37, due to an update from the 3.5.x series to the 3.6.x series.
> > 
> > I'm preparing a gdal-3.6.2-8.really3.5.3.fc37 to address this, please don't 
> > rebuild any dependencies in the meantime, as the new package will bring back 
> > the previous soname.
> > 
> > Apologies for the troubles.
> 
> Hello,
> 
> this is not the first time I saw a bodhi update that breaks dozens of 
> dependencies, goes unnoticed for a week and is automatically pushed stable, 
> only to discover many packages fail to install.
> 
> How come we don't have an automatic check for this? What can be done?

This task (which we tend to call "reverse dependency checking") is
actually one of the more difficult things to implement reliably, and
has been ever since the AutoQA / taskotron days.

Fedora CI does have the rpmdeplint test, which I believe attempts to do
this:
https://pagure.io/rpmdeplint/blob/master/f/rpmdeplint/__init__.py#_227
but it seems to only run that test on Rawhide:
https://github.com/fedora-ci/rpmdeplint-trigger/blob/master/Jenkinsfile#L30
I am honestly not sure why. Additionally, Fedora CI triggering always
(AIUI) runs tests in the context of a *package* not an *update*, which
means it will produce quite a few 'false failures' in the case where
the rebuilt dependencies are in fact bundled in an update with the
bumped library. Additionally, rpmdeplint often 'false fails' for other
reasons (commonly internal package conflicts which aren't really a big
problem), and so it cannot be set as a gating test at present even on
Rawhide.

openQA will catch cases like this only when the update is a critical
path one (so openQA actually tests it) and the broken dependency is in
a package that's within the scope of one of openQA's tests.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@xxxxxxxxxxxxx
https://www.happyassassin.net



_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux