Re: RPM database duplicate entries

[Jeff Johnson <jbj redhat com>]

On Fri, Aug 01, 2003 at 04:00:33PM -0400, James Olin Oden wrote:
> On Fri, 1 Aug 2003, Tapan Kamat wrote:
> 
> > Hello everybody
> > 
> > Is it possible to install 2 different versions of the
> > same package on your system using rpm binaries such
> > that your database keeps a record of both ? 
> >
> Yes.  Use -i rather than -U.  At one time you could even 
> do something like:
> 
> 	rpm -Uvh foo-1-2.i386.rpm foo-1-1.i386.rpm
> 
> and end up with duplicate entries (this may still be the case).

(aside) No longer the case, not that it matters much. rpmAddInstallElement() is
not the proper place to start discarding packages, that policy needs
ratcheting one layer up, to rpmInstall(), wherein other equivalent
policies like --freshen are implemented.

>  
> > eg. can I install apache-1.0 and apache-2.0 on the
> > same system such that they dont overwrite each other ?
> >
> No, at least not without them being built as relocatable 
> packages.  I don't think you can relocate a package without 
> relocations (is this correct Jeff?).
>  

All file paths are potentially relocateable with --badreloc specified
on the command line. Complete paths only, either directory or file, but
partial paths could be done too if someone is nuttier than I am. ;-)

Prefix: is merely a hint to the end-user that someone may have actually
looked at file contents to insure that, indeed, the contents will
function if installed someplace else. That "hint" should have the
guarantee by convention, making a package relocateable is more than
just adding
	Prefix:
to a spec file.

That's what's wrong with --relocate by design, the lack of guarantee (and
no means of enforcement/detection) of functionality if file paths are
(trivially) rewritten. Providing that policy guarantee requires changes
to packages, not just rpm.

(asude) The other thing that's wrong with --relocate is that it keeps breaking
in rpm, mostly becuase I (and Red Hat) *never* relocate, rebuilding the
package is far more likely to lead to success, particularly when
dealing with something as complicated as apache-1.0 and apache-2.0.

(aside) rpm-4.2.1 now has a (ahem) canary-in-the-mine-shaft production
use of --relocate to handle ia32 installs on ia64 automagically that
should be sufficient to stabiloize the functionality.

> > Also, even if they do, will the database keep a record
> > of both packages being installed at the same time ?
> >
> If they were relocatable, and you relocated them yes.  What I don't 
> know is what happens when you relocate the same rpm (i.e. same NEVR) 
> twice?
> 

Identical NEVR but different A (N == name, E == epoch, V == version,
R == release, A == arch) is in the process of going into production rpm-4.2.1.

So far seems workable, but what's crazy is
	*WHY* should anyone want to mix and match elf32 and elf64?!?
Choose one and be happy imho. ymmv, but you've been warned.

(aside) This also means that the A needed to be added to args to enable
choosing one of two identical NEVR packages that differ with A,
--allmatches is too feeble a mechanism.

This is currently done with any of
	rpm --erase N.A N-V.A N-V-R.A
i.e. the known A's that are suffixed after a . are interpreted as arch.

73 de Jeff

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