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

RE: Managing multiple simultaneously installed "package instances "

Having read the rpmlib section of Maximum RPM and taken a look at the 4.1
source, am I right in saying that the "primary retrieval key" that is our
candidate to represent the "package instance" is the "record number" used as
an offset to retrieve records from the RPM database by rpmdbGetRecord()?

So the job at hand is to implement a command line argument like "--instance
#" or "--record #" to restrict selection to a single record from the
database (via the RPM Library API, of course).

In searches of the RPM database, the record number is returned as the
recOffset field of the dbIndexRecord structure ... is that correct? So a
user supplied record number could be used to filter the result set of a call
to rpmdbFindPackage ... resulting in a single package instance, or none if
the supplied record number and package name do not match up.

It seems that the balance of API calls that manipulate installed packages
either take a record offset directly (like rpmRemovePackage()) or a Header
pointer (like rpmVerifyFile()) which I imagine is acquired via
rpmdbGetRecord ... is this correct?


-----Original Message-----
From: Jeff Johnson [mailto:jbj@redhat.com] 
Sent: Tuesday, March 11, 2003 3:35 PM
To: rpm-list@redhat.com
Subject: 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
> 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
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

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
> 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
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

Rpm-list mailing list

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