Bug 67697 - GUI rpm tools give less than perfect info on package status
GUI rpm tools give less than perfect info on package status
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
7.2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-06-29 17:16 EDT by jdg
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-06-29 17:24:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description jdg 2002-06-29 17:16:44 EDT
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.
Comment 1 jdg 2002-06-29 17:23:58 EDT
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
Comment 2 Jeff Johnson 2002-07-01 11:10:30 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.