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.