Slashdot Mirror
Fedora Project to Help Revitalize RPM
-=Moridin=- writes "The Fedora Project has announced plans to revitalize RPM, the package manager used by many Linux distros. According to the announcement, 'Job #1 is to take the current RPM codebase and clean it up, and in doing so work with all the other people and groups who rely on RPM to build a first-rate upstream project.' For more information, see the the RPM web site and the new wiki-based RPM FAQ. The issue of RPM's upstream development has been a thorny issue ever since Jeff Johnson, the original maintainer of RPM, left Red Hat."
A better comparison would be dpkg to RPM.
Apt is a program that automatically resolves dependencies and fetches packages to install, among other things, and it sits on top of a packaging system, like dpkg or even RPM.
As for dpkg vs RPM, I can only say that I've never had as many problems with dpkg as RPM, especially when installing 3rd-party (unofficial to my distro) packages. I've also had fewer instances of "dependency hell" with dpkg than with RPM, and it's always been easier to fix when I have, but that has more to do with the package and distro maintainers than it does with the packaging system.
Yum, a popular RPM-based manager (like apt, but specifically for RPM) was certainly a total piece of shit the last time I tried it. Took about 10 times as long to do anything as apt would have for the same operation, and I'm not exaggerating. Maybe it's gotten better, but as recently as a couple years ago it was a huge pain in the ass to use. Apt for RPM seemed pretty good at the time, but I've not used it since. I don't even bother with RPM-based distros anymore, as, of the three systems I've used (dpkg+APT, Gentoo's Portage, and RPM) it was, hands down, the worst. It may be better these days, but then again I've found the recent Fedora builds that I've tryed out make me feel restricted, while simultaneously making me do more work than a modern dpkg-based distro probably would. For some reason, distros based on Debian seem to pick better defaults for newly-installed packages than RPM-based ones do, though I don't know why that is.
For reference, I've mostly used Mandrake, Debian, Gentoo, and Ubuntu over the years, with lesser but non-trivial amounts of time spent with Red Hat/Fedora and Slackware, and a tiny bit of time with Suse, so any bias in my opinions on the matter may be tied to this, but I really have found that package management was only ever something that I dreaded dealing with when I was on Mandrake and Red Hat/Fedora, and I didn't work with Suse enough to form an opinion on it. Switching to mostly non-RPM distros a few years back made most of my package management woes disappear instantly.
Apt is certainly not deprecated in favour of aptitude, as aptitude is a frontend to apt. One could argue that aptitude is superior to apt-get, but it should be noted that apt-get also has autoremoval, at least in Ubuntu. Try apt-get autoremove.
Personally, I have always used apt-get instead of aptitude.
The requirements for packaging for Windows is fundamentally different than for Linux. The differences between distributions can be extremely large as Geekmeister mentioned, much larger than differences between versions of Windows, and there are innumerable places where things could vary.
How would a universal package for apache, for example, know how to set up starting and stopping the service? Different distributions put the scripts in different places, and use different formats and conventions for the scripts. In future versions of Ubuntu, the scripts won't even be shell scripts, and will be handled in a fundamentally different way. The meaning of installed dependencies is also different. USE flags in Gentoo would have to be considered, for example.
In order to make a package format that would work for everyone, the system would have to resemble autoconf, and check for every imaginable aspect of each system. Like the configure scripts of autoconf, doing so would make installation absurdly slow. The package format would also have to include many versions of files with the same purpose, making the packages very large.
In short, perhaps such a package format could be made, but it would be inferior to the formats that already exist. In fact, this is the case. Formats like autopackage and klik exist, but they are markedly inferior in terms of stability, reliability, elegance, and usefulness for non-trivial packaging requirements, and usually only used for end-user applications with few dependencies.
The problem with that theory is that it doesn't make any sense. Even in the Debian world, I'll come across .deb packages that need manhandling (instalation, removal, retrieval), and the debian command-line utilities (e.g. dpkg) are always simple to use when I need to. 'dpkg -i' to install, 'dpkg -r' to remove, 'dpkg -l' to list matching packages, and 'dpkg -S' to find out what owns a file.
If you look at the output from 'dpkg --help' and compare it to RPM's, RPM provies a much longer list of options, the vast majority of which no one ever uses, burying the commonly-used functionality in a sea of terse explanation.
The RPM tool needs to be replaced - possibly with another version of the tool, but removing all the extra cruft from the way it's used. It makes no sense to say 'Well, of course it's messy because you shouldn't be using it'. If the tool exists, it should be usable.
Even with the APT frontend picking up the slack, Debian has managed to keep dpkg easily usable and keep the help options straightforward, to the point where I rarely have to dig for what I need to do. When I go to work and have to work with the package management tools on Fedora (yum on our workstations) or RHEL (RPM on our servers), I hear nothing but complaints about usability, speed, and reliability from coworkers.
RPM needs an overhaul, badly, but I doubt it'll get the one it needs.