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: http://www.redhat.com/mailing-lists/rpm-list/msg18062.html 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. Yes. : > 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 | firstname.lastname@example.org | 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!
Description: PGP signature