Red Hat Bugzilla – Bug 10776
[RFE] make RPM deal with .[arch].rpm in packagename
Last modified: 2008-05-01 11:37:55 EDT
A common mistake people make with rpm is this:
# rpm -e foo-1.5-2.i386.rpm
error: package foo-1.5-2.i386.rpm is not installed
# rpm -i foo-1.5-2.i386.rpm
package foo-1.5-2 is already installed
If one understands the distinction between "package name" and "file name",
the problem is clear. But to many new users, this is really confusing. I've
had *many* people tell me "Oh, rpm sucks. It's really easy for it to get
confused about what's installed.", and when pressed for justification,
quote something similar to the above.
A solution would be: when a query for a package results in it not being
found, check to see if the request was for something ending in
".[arch].rpm". If it is, print a warning message explaining that this
probably isn't what they meant to do.
Optionally, go ahead and act on the package which they like meant.
(Maybe only for non-destructive actions? Maybe only if they give --force?)
I highly suspect that this comment on slashdot
for example is symptomatic of the problem.
"[...] (and RPM sucks!!) Installing software is easy, but removing it
can be irritating."
I'm not suggesting that software should be engineered to appease the sucks/rules
crowd, but it seems like a little technical change could do a lot to ease a
widespread (and detrimental) myth.
This problem will be addressed after rpm-4.0 is released.
rpm must be able to deal with both packag and file names,
as this is what rpm manages. If anything, the confusion is
going to get worse in the future, as rpm-4.0.3 has file
manifests (i.e. glob expressions contained in a file used
to generate a package manifest), and rpm-4.1 is going
to manage public keys used to sign packages by permitting
detached mime-type signatures on the command line. In fact,
I can already see the need to permit tarballs and other archive
formats, as well as file names on the rpm command line, to be
used to generate header meta-data on the fly. The only other
alternative is to force myriad and sundry command line options
to identify what the next argument, I'd rather just deal with
/etc/magic, thank you.
So, while I understand the confusion, I don't believe that there's
any viable implementation to remove the confusion between
package names and file names. And I believe the situation is
going to get worse.