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):
Try to install a package twice.
Steps to Reproduce:
1. Install a package.
2. Install it again.
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(
This is a feature of rpm, not a bug. Installing multiple instances
of an identical package even makes sense when you consider
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".
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 ...
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.
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)
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 :-)
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)
There's no way to change the existing behavior of --install, --update
and --freshen no matter how surprising you may find this.