Bug 57262 - New rpm package is allowing multiple instances of package without --force
Summary: New rpm package is allowing multiple instances of package without --force
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: rpm   
(Show other bugs)
Version: 1.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2001-12-07 23:49 UTC by Bill Crawford
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-12-09 20:38:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Bill Crawford 2001-12-07 23:49:45 UTC
Description of Problem:
Running "rpm -ivh kernel-2.4.16-0.6.athlon.rpm" (forgetting that I had
already installed it yesterday) I saw no errors/warnings, no "file ...
conflicts ..." or anything ... but nor did I see " ... is already
installed" which I would have expected.

Version-Release number of selected component (if applicable):

How Reproducible:
Try to install a package twice.

Steps to Reproduce:
1. Install a package.
2. Install it again.
3. Watch.

Actual Results:
Didn't squawk.

Expected Results:

Additional Information:
Well this makes a change from a screen full of messages about conflicting
files ... but I'd like to have seen some feedback.  I don't want to find I
have multiple instances of the same package.  Especially as I have to
remove it altogether and reinstall to fix (what if it had been glibc :o(

Comment 1 Jeff Johnson 2001-12-09 17:24:34 UTC
This is a feature of rpm, not a bug. Installing multiple instances
of an identical package even makes sense when you consider
file relocations.

OTOH, having multiple instances of an identical package is
mostly harmless. The last package installed "owns" the files,
the files in previous instances are marked as state "REPLACED".

Comment 2 Bill Crawford 2001-12-09 18:58:57 UTC
I understand that, but the behaviour seems to have changed (older versions would
have required --force or --replacefiles to do this).

Another take on this: the Solaris pkgadd will re-install an existing package,
but it overwrites the existing instance (and actually does the equivalent of rpm
-V on the files/paths that already exist, and leaves them alone).

Please at least make this require a flag, like it used to?  If nothing else the
current behaviour will bloat the RPM database a little :o)  I would rather get a
warning if I've been trigger-happy and tried to reinstall something that's
already there ...

Comment 3 Jeff Johnson 2001-12-09 19:16:29 UTC
I'm willing to consider anything, but I am actively trying
to simplify rpm CLI operation rather than adding Yet
More Obscure Options and such.

Even if the behavior is different from previous versions
or rpm, that doesn't mean that the behavior was correct
or simple in the first place. Ditto pkgadd. rpm database
"bloat" for a couple of bogus headers is nothing compared
to the existing bloat with %changelogs from forever. No
the text can't be dropped/deleted, as it's part of the
original header and I'm going to need an exact image of
the original header in order to support digital signatures.

However, if you can give me a reasonable example, other
	I want to do "rpm -Uvh ftp://...../*
(i.e. my interpretation of "trigger happy" :-)
I'll try to accomodate.

Comment 4 Bill Crawford 2001-12-09 19:39:03 UTC
I know what you mean about the options (rpm is a little baroque :o) but the
thing is, doing "-Uvh" when the package is installed stops and says

	package kernel-2.4.16-0.6 is already installed

I'd like -ivh to do the same, it's what I expected (I'd made a mistake, and I'd
prefer to get "it's already there, you idiot").  The pkgadd example is real (and
something I like about it, because if you know a package is corrupted, it's very
easy to fix by just installing the package again).

I'm sorry for all the noise when I know you're pretty busy.  I didn't realise it
was the intended behaviour, so I assumed it was a bug.

There's an easy fix for the %changelogs, btw ... trim them in the .spec file :o)

Comment 5 Jeff Johnson 2001-12-09 19:45:43 UTC
Hmmm, --freshen has semantics that start to address the
	package already installed problem

Reinstalling a package to fix corruption is certainly doable
with rpm. What am I missing about pkgadd?

Yup, deleting the %changelogs in the spec files would "work",
but is outside the scope of what rpm can attempt :-)

Comment 6 Bill Crawford 2001-12-09 20:38:38 UTC
OK, changing this to an RFE, low priority (there are more pressing things) and
clarifying a little ...

The --freshen option is really useful, but always has "upgrade" semantics, so
isn't much help with kernel packages, because I always want to install those,
not upgrade (hence my mistake).

I was caught out because had I been doing an upgrade, I would have got the
warning message and (without the --force option) nothing would have been
changed, either in the RPM database or in the filesystem.

I think there is a consistency argument for making --install behave the same as
--upgrade when the package is already installed with the same (version, release,
location) -- think of it as satisfying the "principle of least surprise" I

I'll stop whingeing now ;o)

Comment 7 Jeff Johnson 2001-12-19 19:28:13 UTC
There's no way to change the existing behavior of --install, --update
and --freshen no matter how surprising you may find this.

Note You need to log in before you can comment on or make changes to this bug.