In the past few years, changes in the Linux world helped the operating system gain acceptance in the mainstream market. Package management has played no small role in this process. Thanks to dependency checking, the overall system consistency is kept. Thanks to file databases, removal of unneeded software is as easy as installing new, up-to-date precompiled binaries that are guaranteed to work on your system. Sysadmin skills are not a prerequisite to run Linux anymore; C and makefile knowledge are no longer required. RPM and Debian packages ruled the world, the first adopted by the vast majority of commercial Linux distributions. In a quick glance, the two systems are just two implementations of the same idea, with no major differences. A few details, however, make a big difference in the auto-updating process.
We first met automatic package retrieval and installation in the form of apt-get. Debian users are glad to have such a wonderful tool. One step ahead of package management, users can now keep all their packages up-to-date, and add/remove packages tied to an intricate dependency graph, by issuing a single command. And, even better, APT was designed to be system-agnostic, so no matter if you use .debs or .rpms; we'll all be happy.
Well, not quite. Mixing APT and RPM is an obvious step in making users of RPM-based distributions happier, and probably every vendor has considered implementing it. A few design problems, however, have made this goal not so easy to accomplish, and many distributions decided to use their own updating system. This is not a very good situation; it fragments the user (and potential developer) base, it may create incompatibilities, and it duplicates development effort. On the other hand, apt-get is ready, has proven to be reliable, and has a nice set of companion utilities such as apt-cache, apt-move, apt-zip, and gnome-apt.
Just like a painter who paints the floor of a room and gets trapped in a corner, certain features in RPM seem to have been designed to make integration with APT impossible (which makes a lot of sense if you consider that RPM is older than APT). File dependencies, for instance, make your reverse dependency database grow to insane proportions, and the existence of packages optimized for different processors on the same architecture doesn't help. But that's not the problem. Thanks to the efforts of Alfredo Kojima of WindowMaker fame, now working at RPM-based distributor Conectiva [Ed: Conectiva is also Mr. Matsuoka's employer], most technical issues have been quickly addressed and, despite claims that it couldn't be done, it actually works. So is updating RPMs now as simple as updating Debian packages?
Yes and no. Yes, you can install, remove, and update packages in a painless process with all dependencies resolved. No, it's not the same thing. RPM packages can't be configured interactively. They won't ask you if you want to keep the current version of a configuration file, install a new version, or compare the two versions. They won't stop services before updating and restart them afterwards. The MTA won't ask you a few questions and configure itself. They won't even issue a warning to the administrator. We need to walk one more step to have it work properly.
First of all, it would be a valuable addition to RPM to provide some mechanism to configure all unpacked but unconfigured packages. Pre- and post-install scripts, as well as pre- and post-removal scripts, should be executed appropriately to allow smooth upgrading of running services. Package maintainers would have to add such scripts to their packages and make sure they'll not break the system the package is being installed on, keeping in mind the diversity of RPM-based distributions out there. Auditing, predependencies, package flags, and auto-deconfiguration functionality must be implemented. Small details like "obsoletes" with version numbers should also be provided, and package priorities -- at least "essential" marked packages -- are a nice thing to have.
Most of the effort required by such a change would be in the packaging policy. A few issues still remain unsolved, most notably how to handle multiple versions of the same package installed on the system and what to do with packages with the same name but different vendors.
Indeed, the above description matches the current features of Debian packages. But all these features, regardless of what packaging system they come from, are important to making auto-updating easy, reliable, and not likely to stop your system due to misconfiguration, removal of an essential component, or even security holes introduced by mismatched configuration files. "So what's the point," you may ask, "of implementing something that's already there, just under a different name?" A few issues must be considered:
Is it time to change RPM to allow smoother auto-updating? Will it be the start of a road for .rpm and .deb interoperability, or will it lead us in the opposite direction, restricting the installation of software packages to the ones specifically designed for your RPM-based distribution? Should the LSB be concerned about these issues? What role will be played by auto-rpm, up2date, and other auto-updating tools? Or shall we leave things as they are, and declare that full apt-get functionality is an unneeded feature?