how rpm does it (Re: Dpkg Update Proposal)
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
Reply to: