Bug 57262
Summary: | New rpm package is allowing multiple instances of package without --force | ||
---|---|---|---|
Product: | [Retired] Red Hat Raw Hide | Reporter: | Bill Crawford <billc> |
Component: | rpm | Assignee: | Jeff Johnson <jbj> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 1.0 | Keywords: | FutureFeature |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2001-12-09 20:38:44 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Bill Crawford
2001-12-07 23:49:45 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". 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 than 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 guess. 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. |