ESR: Goodbye Fedora

[Sam Varshavchik]

M. Fioretti writes:

> On Wed, Feb 21, 2007 18:29:32 PM -0500, Sam Varshavchik
> (mrsam at courier-mta.com) wrote:
> 
>> Five-seven years ago, rpm was, hands down, the technically superior package 
>> management system.  But it failed to keep up with the times.  Rather than 
>> fixing fundamental defects in rpm
> 
> which fundamental defects, sorry?

A detailed explanation would -- I'm afraid -- run for much longer than I'm 
willing to type, after a hard day at the office.  But, a brief, concise 
summary:

• The way that the arch part of a package's "definition" is processed is 
fundamentally broken.  Review the list's archives a few years back, when the 
kernel-source package switched arches (from arch to noarch, as I recall) and 
what barrels of fun everyone had, as a result.  And, someone else already 
mentioned the massive, ugly, repulsive hack that multilib support is.

• Try a "yum update" when a dozen, or so, packages need tobe updated. Press 
CTRL-C after half of them are installed.  Enjoy spending the rest of the day 
undoing the resulting mess, and cleaning up all the puke in your filesystem, 
and the rpm database.  This is completely U N A C C E P T A B L E for such a 
critical infrastructure element as the system package manager, to leave the 
system in a completely incoherent state that cannot be repaired 
automatically.  It must _not_ vomit all over itself, like it does now.  _No_ 
excuse for this, whatsoever, no matter what anyone tells me.  My package 
manager -- even if it gets SIGKILLed past its equivalent of a "point of no 
return", then the next time it runs it will simply finish whatever 
transaction it was in the middle of, installing and removing whatever didn't 
get installed or removed.  This is not rocket science.  If I can implement 
this level of error recovery in my package manager, there's no reason rpm 
couldn't.  And I never have to deal with the wonderful dangling locks in the 
Berkeley DB's layer.

• Speaking of that:  Berkeley DB.  Enough said.

• Kernel modules.  Enough said.

• Epoch.  Enough said.

• Bottom line: dependency resolution logic in rpm is too primitive, and 
simply cannot cope with many present-day cases.  "Kernel modules, enough 
said" and "Epoch, enough said" are just two manifestations of this deeper, 
underlying shortcoming.

• rpm croaks if some dependency is missing.  The solution was yum, a layer 
on top of rpm.  But yum's functionality really belongs in rpm.  Furthermore, 
if the missing dependency is for a package in a repo not already known to 
yum, yum will still croak, because it won't know what to do.

There's no technical reason why an rpm file cannot include the URL of any 
repositories that provide packages any needed dependencies, together with 
the repositories' keys.  The packager doesn't even need to compile such a 
list manually, it can be done automatically by rpmbuild.  All that a package 
needs to do is identify its own yum repository.  Then, when rpmbuild 
assembles a list of the new package's dependencies, it looks up which 
packages provide the new package's dependencies, pull those package's 
repository URLs, and add them as the new package's "downstream" URLs.

Then, if a dependency cannot be immediately resolved from the rpm database, 
and it's not found in any of the existing repositories, and the package has 
a pointer to a repository URL that doesn't match any of existing repo's 
URLs, rpm could optionally prompt for permission to add a new external 
repository, and then use it to pull down the required packages.

There's more stuff I can bitch about, but these are what I believe are some 
of the main design defects/shortcomings in rpm.


-------------- 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/20070221/a63f6c30/attachment-0001.sig>