Dependency Hell

Jonathan Hutchins hutchins at opus1.com
Tue Mar 5 00:35:53 CST 2002


> -----Original Message-----
> From: Brian Densmore [mailto:DensmoreB at ctbsonline.com]

> I thought that RPM already had the capability to check and pull RPM's.

All the base RPM package will do is whine about the ones you didn't specify.
Some of the shells will try to find the resolutions, none really works well
at it.  

RPMFIND, for instance, is frequently wrong about what the latest available
version of a program is, simply because their archives are only sporadically
up to date.  Because listing a package on their system is up to individual
contributors who built the package, the consistency of the quality checks is
not good, and you can end up putting a Mandrake RPM on a RedHat system,
which will then throw something else off, and before you know it you're
facing 32 package upgrades to install a blinkeylight program, which will
either fail to download or if successful will leave you with an un-bootable
mess.

Ximian's Red Carpet likes to do things like offer 45 urgent security
updates, then abort with the message "Probable cause:  A downloaded package
was corrupt".  As in one out of 45, guess which.  I tried it this weekend,
hoping maybe to solve the mysterious "unable to locate HTML editor, can't
create mail" error in Evolution, and it tried to remove the kernel - without
replacing it.  Fortunately, it failed.

As I recall the KDE package management shell, it doesn't do a good job of
tracking down required packages you haven't selected.  If you copy the list,
go back and re-run it, and select the right packages, you can luck out.

I understand that apt-get is much better, but I suspect that it may be
dealing with a significantly smaller database.




More information about the Kclug mailing list