On Sun, 04 Jul 2010 14:40:20 +0200, Till wrote: > > It's fairly easy to verify other broken deps, too: > > http://admin.fedoraproject.org/updates/compat-db-4.7.25-3.fc13 > > For me it is not that easy, because the information is confusion (or not > clearly arranged) or not directly accessible, e.g. to understand the > compat-db problems one needs to look at the koji page for the list of > built rpms. Hmmm ... most of the broken deps are of the form something requires something-unavailable where "something-unavailable" either has never existed before or is gone because of an update. One could attempt at writing code to automate checks that help with interpreting other results in the broken deps report. 1) Is "something" the newest (EVR)? If not, it would be an old multiarch package that is no longer multiarch. (Else, the repositories are broken and a later build of "something" is missing.) [1] 2) If "something-unavailable" is of the form "key = value", does anything still provide "key"? If so, show latest EVR, and "something" will need an update, or is a missing obsolete, or is an old multiarch build that is missing a multiarch update. 3) If "something-unavailable" is a SONAME, try to find a similar SONAME and inform the library packager. This is not 100%, but is done already as in the Rawhide broken deps report. | Broken packages in fedora-updates-13-i386: | | compat-db-4.7.25-3.fc13.i686 requires compat-db46(x86-32) = 0:4.6.21-3.fc13 | compat-db-4.7.25-3.fc13.i686 requires compat-db45(x86-32) = 0:4.5.20-3.fc13 > So here the release of compat-db needs to be increased to > 11 in F13? -12.fc13, because compat-db45 and compat-db46 for F12 updates are -11.fc12 and newer than -3.fc13 [1] Some multiarch broken deps in F12 exist for a long time without the packagers showing interest in fixing them. That isn't anything like encouraging. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
