From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 Description of problem: both kpackage and gnorpm report identical (duplicate) name, version, and release info. In certain cases, this reflects that installs were re-done (albeit incorrectly, but that's not the point). The package _components_ (which is what really matters) may be fine, but there are duplicate _database_key_ entries. This is in direct conflict with the database normalization rule of "No Duplicate Records". Since both kpackage and gnorpm act this way, I assume that the problem lies in the database key construction algorithms. rpm -Uvh does not fix this, although it maybe should... Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. re-install any package with rpm -v -i -h --force 2. go look at the results in gnorpm or kpackage 3. Q.E.D. Expected Results: --force on install should replace files, packages - AND ALL RELATED DB KEYS!!! Additional info: A user trusting that he/she is only removing a 'duplicate' DB entry through the GUI tools provided, does not expect to hose their system.
Now that I've got room to write, I should say that I've spent nearly 20 years in this biz, including 6 years at www.empress.com, so I know a little about how to describe what I see, but this could really be a 'wishlist' item. There's no way in hell that two completely identical NAME+VERSION+RELEASE entries should ever come into the end-users sight. 'Cause if you see duplicates, nine out of ten times, you'll think that you can delete one of them, but you can't, 'cause they _both_ seem to point to the same _physical_ data elements. How, do I know this really sucks? 'Cause your rhn website reads the _same_ info, and tells you that you got 40,000 errata to apply... :^p
rpm -i has always permitted duplicate names (e.g. for the kernel package), and has always permitted even identical package installs (which even makes sense if --relocate is used to change install location). You want to to use -U,--update, or -F,--freshen for almost all rpm package installs from the CLI. The kernel package is the only exception that I can think of. I'm not sure what "hose their system" means. If anything, this is a defect in gnorpm/kpackage handling duplicate/identical package installs. Reopen and assign the bug to gnorpm/kpackage if there's a problem here.