Re: Checking dependencies in packages selected for installation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


Attachment: pgpqX6SXJeKtF.pgp
Description: PGP signature

[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux