As I said before, rpm does have the capability to install 2 different versions of a package simulantaneously. Here's how it works, to the best of my knowledge.
User interface: Rpm differentiates between installing a package and upgrading a package. Installing a package (rpm -i) simply unpacks the rpm file, registers it in the database of installed packages, etc. If an old version of the package is present, it will not be removed. Upgrading a package (rpm -u) means that the old version of the package that was installed (if any) is removed at the same time the new one is installed. So rpm's method of upgrading is the same as dpkg -i, whereas dpkg has nothing equivilant to rpm's method of just installing a package. Oh and by the way, this user interface tends to confuse new users (at least it did me) who accidentially install many versions of the same package because they arn't aware they should be upgrading it instead. I forget how rpm allows removing of one version of a package while leaving another version of it installed. Back end: I don't know much about this. I can intuit some things. Rpm can keep track of multiple versions of the same package that are all installed. Presumably, this means its package database indexes the installed packages by both package name and version, instead of just by package name as dpkg does. What happens if you try to install version bar of a package while version foo of that same package, which contains files of the same name, is installed? Rpm will happily overwrite version foo's files. What happens if you then remove version foo? I'm not sure, it's been a while ;-). I can say that rpm doesn't deal with this very well. It either has to leave version bar's files around, or delete them, either action leaves the installed version foo in an inconsitent state. Given the above, it's clear that rpm's method of doing this is really only useful for library packages, in which 2 different versions contain files with entirely different names. (You might ask, what about /usr/doc, wouldn't it be the same in both versions of a library package. The answer is that rpm packages use /usr/doc/package-version/ as the doc directory.) But it does work tolerably well for those library packages. Of course, if redhat had anything like update-alternatives, it could be more useful for other packages too. Applying this to dpkg: User interface: If we wanted to make dpkg have this capability, we could add a new command line flag, say "--keep-old-version" that makes "dpkg --keep-old-version -i" behave like rpm -i does. We would have to come up with some method to allow dpkg to remove one version of a package while leaving another version of that package installed. Back end: Dpkg would have to change how it parses the status file, and presumably how it stores the information about installed packages in memory, so it in effect considers different versions of a package as different packages, if --keep-old-version were passed to it. Dpkg already doesn't allow 2 packages to be installed that contain the same files (unless --force-overwrite is on), so it doesn't run into the problem rpm runs into with installing multiple versions of a package that contain the same files. (Or does it? The same issues seem to apply with --force-overwrite. But I guess dpkg does the Right Thing, whatever that is. ;-) Applying this to deb packages: For library packages, which contain different files from version to version, we really need do nothing special. For packages like ncftp and ncftp2, update-alternatives can be used (as it is now) to ensure that the 2 packages contain only differnet files. However, both these cases do leave us with the problem of /usr/doc/<package>. We would have to either change that to /usr/doc/package-<version> for those packages, or come up with some other solution. Some things I haven't dealt with: Apt would probably need to be made smart enough to figure out when it needs to tell dpkg to --keep-old-version a package. The dselect user interface would probably need modifications both so it can display multiple versions of a package that are all installed, and so it can allow users to change which versions are installed. The ftp site would probably need some major changes made to it to allow mutliple packages with the same name to be on it. -- see shy jo
