ESR: Goodbye Fedora
Sam Varshavchik
mrsam at courier-mta.com
Thu Feb 22 00:06:35 UTC 2007
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>
More information about the fedora-list
mailing list