Old broken packages

Shahms King shahms at shahms.com
Mon May 22 19:41:33 UTC 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is related to an earlier message about removing the obsolete and
broken arch-specific epydoc package. That specific package has been
fixed, but the general problem of old architecture specific packages
breaking newer (properly) noarch packages remains.  I encountered the
problem most recently when trying to install python-reportlab which,
like the epydoc package, has both a newer, properly compiled noarch
package and a FC3-era i386 package in the repository.  And, like epydoc,
the old package breaks updating, installing, etc. the new package.
Unlike epydoc, the offending python-reportlab package explicitly
requires: python < 2.4 and therefore fails to install rather than simply
failing to work.

I'm not precisely sure where the blame for this lies, but there are
certainly a number of candidates:

1. Propagation of packages from old releases to new releases doesn't
adequately compare noarch and arch packages.  Both of the problem
packages I have found are *FC3* packages that have been copied,
unchanged, into both FC4 and FC5 despite the existence of newer and
properly built noarch packages.

2. Similarly, these packages are not being pruned when newer versions
are pushed, rather the old arch-specific packages are sitting in the
repository.

3. yum fails to take noarch packages into account on install or update
when any arch-specific package exists, regardless of the epoch, version
or release.

I strongly suspect the problem lies with RPM always comparing an
arch-specific package as "newer" than a noarch package, but I'm not certain.

Note that these problems *appear* to have been fixed in rawhide as the
extras development repository does not contain the offending packages.

Additionally, trying to track down any potential problem packages is
difficult as repoquery will not check versioned requires and insists
that python-0:2.4..2-3.2.1.i386 provides "python < 2.4", which it most
assuredly does not.

- --
Shahms E. King <shahms at shahms.com>
Multnomah ESD

Public Key:
http://shahms.mesd.k12.or.us/~sking/shahms.asc
Fingerprint:
1612 054B CE92 8770 F1EA  AB1B FEAB 3636 45B2 D75B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEchPt/qs2NkWy11sRAtbeAJ4h2O+t6G8ILJsJIRlJfyhasVtOngCdG2wP
4/1BRYxCccmFIK1s7n9srPg=
=o8J0
-----END PGP SIGNATURE-----




More information about the fedora-extras-list mailing list