[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Managing multiple simultaneously installed "package instances"

Circa 2003-03-11 15:23:41 -0500 dixit Tristan Van Berkom:

    [Anthony Shortland:]

: > Although RPM makes provision for both multiple versions 
: > of a package and multiple releases of a 
: > given version, it doesn't appear to make
: > provision for manipulating multiple simultaneously installed 
: > versions or version releases of the same package on a system.
: Is it wise to say that more than one version of PACKAGE_NAME
: can be simultaniously "installed" on one given system ?

Yes.  I do this on a regular basis when building custom OpenSSL
packages and rebuilding applications which depend on them:


This is slightly different from what Anthony is speaking of, however.

It is possible to have more than one package with the same NEVR
(name/epoch/version/release) installed on the same system, in the same
package database, by relocating all the paths in one of the packages.
This might even be useful in chroot environments.

It is also possible to have more than one package with the same NEVR
installed, but with differing architectures, especially if the packages
do not have conflicting files.  This might be useful for fileservers
that serve diskless (or partially diskless) clients with multiple
architectures, or to have multiple kernels for slightly different
architectures installed (i386, i686, etc.).

: if *anything* fails during a software
: upgrade/installation/downgrade/erasure
: the database will yield bogus information. but what can you do ?
: if a package doesn't "completely" erase; its not right to say that
: it's still there and its not right to say that its gone.

This could certainly be indicated by having more than two possible
states in the package database ("on" [listed] or "off" [not listed]).
In fact, the package database ought to be able to carry state such as: 
"installed, but failed during %post", or "installed, but failed during
erase".  For all i know, maybe RPM already even maintains this sort of
state in the package database....

: I would hazard a guess to say that this "-allmatches" `rpm -e' option
: is to ease the job of reapairing broken rpm databases.

I have no idea about the intent of --allmatches.  The *effect* is to
allow uninstallation of multiple package instances.

:      "Remove  all  versions  of the package which match PACKAGE_NAME.
:       Normally an error is issued if  PACKAGE_NAME  matches  multiple
:       packages."
: I havn't checked but I'm sure that "Normally" means `rpm -e' without
: the --allmatches option.


: > How does one emulate the Unix package instance capability under RPM? 
: I guess you can pretend that multiple package instances are possible
: while making assumtions about the rpm database (knowing what kind
: of situations leave you in an inprecise database state). you'd
: still end up with a package system that doesn't allow multiple
: versions of the same package to be simultaniously "installed".

You don't seem to know what you're talking about.  It's quite possible
for more than one package NEVR instance to be installed without any
conflict, as RPM is right now.  RPM merely limits the ability to
manipulate such multiple package instances individually after they are
installed.  RPM may also limit the amount of information it maintains
about incompletely installed or uninstalled packages; this issue is
orthogonal to that of multiple package instances.

jim knoble  |  jmknoble@pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
Stop the War on Freedom ... Start the War on Poverty!

Attachment: pgp00010.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []