Checking dependencies in packages selected for installation

Sam Varshavchik mrsam at courier-mta.com
Sat Jan 20 17:57:44 UTC 2007


Tim writes:

> On Sat, 2007-01-20 at 10:44 -0500, Sam Varshavchik wrote:
>> What exactly is so complicated here?  This is not rocket science. This
>> should not take more than a few minutes to compile a list of packages
>> to ugprade.  This is not a complete FC 4 install.  Just the base
>> install, plus X, plus dev tools.
> 
> Its idea of a base install (which might include all manner of things),
> or yours (which would mean only what you've listed)?

Its idea of base install.

> For those updating a system with quite a few things already on it, it's
> a common recommendation to first uninstall some of the larger things,
> like OpenOffice.org.

That's not a valid excuse.  I have my own packaging tool I use for managing 
my own software.  I got so sick and tired of rpm, last year, that I wrote my 
own, to manage by own code.  I can import rpm dependencies into my own 
database (which will NEVER get corrupted like rpm regularly does, see 
below).  It takes me only a minute or two, to suck out all dependencies out 
of rpm, via perl-RPM2.  And, on a beat up old Celeron 500, it takes only 
another three minutes to reconcile RPM's dependencies against mine's, and 
identify any conflicts.  There is no reason, whatsoever, that this crap 
should take an hour to figure out, in anaconda.

The real ugly truth here is that the upgrade path in anaconda is being 
neglected for commercial reasons.

If the 800lb gorilla I deal with, daily, is a typical RHAS licensee -- and I 
have no reason to think that they're not -- most RHAS customers do not 
upgrade their servers.  The servers are all network clients, and RHAS 
gets upgraded on the servers just by loading a new install image.

So there is really not much of a demand from commercial licensees to get the 
upgrade path working efficiently.  I'm sure some of them do it, but it's 
likely to be a minority.

P.S.  This latest upgrade of mine is turning into quite a show.  It's a text 
install, and after every package gets installed, the screen gets slimed with 
a dozen "rpmdb: Lock_downgrade: lock is no longer valid" messages. 
Eventually, it hung with an rpmdb_stat process apparently stuck in an 
infinite loop.  Killing it did not bring anaconda back to life, it remained 
comatose.

After some Googling, it looks like I'll need to nuke /var/lib/__db* and try 
the upgrade again.  Well, I'm checking these dependencies again, for the 
next hour.  Here we go again.

Whoever decided to use Berkeley DB for RPM, many years ago, should be 
smacked upside the head.  Hard.  BDB is garbage.  Stay away from it.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20070120/c4768a0a/attachment-0001.sig>


More information about the fedora-list mailing list