Hide Forgot
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 http://slashdot.org/comments.pl?sid=uselinuxcuz&cid=56 for example is symptomatic of the problem. "[...] (and RPM sucks!!) Installing software is easy, but removing it can be irritating." Another example: http://x38.deja.com/getdoc.xp?AN=603388343&CONTEXT=956003588.994246661&hitnum=21 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.