Joey Hess <[EMAIL PROTECTED]> writes: > 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. That's "rpm -U". > 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. Buried in the Maximum RPM book is a suggestion that you always use -U (which also installs new packages. > I forget how rpm allows removing of one version of a package while leaving > another version of it installed. You can specify packagename or packagename-version to query and remove operations. If you just specify "packagename" to a query op, it will list all versions. Dunno about the delete operation. > 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. rpm will complain if files conflict with another package, and won't let you install the new one unless you force it with --force. > 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. What does dpkg do if you turn on --force-overwrite? > 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. I've suggested to Red Hat in the past that they adopt our package naming scheme. There are a few packages that use the seperate packagename for seperate version scheme. (If you look at the "gnome" directory, you'll find glib10 and gtk10 packages containing older versions of glib and gtk.) > 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. I like our current method of naming the packages after the soname of the library. We should make it explicit policy for packages that contain shared libraries used by other packages. > 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. > ;-) RPM also requires you use --force. (This forces everything but dependencies.) > 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. You would also have to fix dinstall (on master) which toasts old versions of source and binaries. (dinstall is very broken anyways - it wipes out old versions of source packages when other architectures still depend on them, and it wipes out old "binary-all" packages, even if other architecures have binary packages that depend on them. (e.g. xemacs) Steve [EMAIL PROTECTED]
