M. Fioretti writes:
On Wed, Feb 21, 2007 18:29:32 PM -0500, Sam Varshavchik (mrsam@xxxxxxxxxxxxxxx) 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 rpmwhich 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.
Attachment:
pgpR0TisrTZNR.pgp
Description: PGP signature
