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

Re: Managing multiple simultaneously installed "package instances "



On Tue, Mar 11, 2003 at 04:05:09PM -0700, Shortland, Anthony wrote:
> For the time being I've implemented a workaround by concatenating the
> package, version, os and processor names to make a distinct RPM package
> name. e.g.:
> 
> Name        : shutils-2.0-linux-intel      Relocations: /opt/spf 
> Version     : 2.0                               Vendor: (none)
> Release     : 1                             Build Date: Wed Feb 26 07:51:41
> 2003
> Install date: Wed Feb 26 07:52:56 2003      Build Host: w0252sfo
> Group       : pkg/shutils                   Source RPM:
> shutils-2.0-linux-intel-2.0-1.src.rpm
> Size        : 3190994                          License: none
> Signature   : (none)
> Summary     : shutils
> Description :
> GNU Shell Utilities
> 
> ... this feels all hacky to me, but seems the only way to manage the
> co-deployment of multiple instances of relocated packages.

Hacky or not, rpm was designed for a single management domain. Those
design constraints show up all over the place, single arch/os scoring,
single package name, single database, etc.

So the best current solution is what you are doing, with relocated paths wired
into multiple builds of packages, differentiated by name, because that
preseves a single management domain.

Slightly more advanced is to use multiple databases, say one database per
arch-os combo. Common, core dependencies can be factored into a virtual
package if necessary. What will still get you is the single arch per host,
but that can be worked around by pre-selecting what packages to install where.

Multiple (i.e. 2) databases will "work" just fine for, say, a LTSP server
with one arch for the server, while the client trees are another arch.

Any other multiple, co-deployed, installed instance scheme is gonna be
a bear to maintain with rpm. Possibly doable, but you're gonna end up
knowing far more about rpm than you ever wanted to know. ;-)

> 
> Is there a discrete package instance stored in the database, then? Could one
> modify the command line interface to accept a fully qualified instance?
> Where can you find the package instance (the query command above doesn't
> seem to report it).
> 

The package instance is the primary retrieval key on /var/lib/rpm/Packages.

Instance #0 in Packages is an int that keeps track of the largest package
instance currently installed. Basically, instance #0 is incremented for every
package installed.

The rest (well, except for __db*) of the files in /var/lib/rpm are inverted
lists with a tag value as primary key, returned data is an array of package
instances. Think: join keys == package instances.

All the instances are displayed with -vv, try
	rpm -qa -vv
using rpm-4.1 or later.

And what's missing is some defined CLI syntax to specify which of several
instances is intended when erasing or upgrading identically named packages.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC





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