Bug 145081

Summary: conflict error message is unclear in biarch because name (NVR) is ambiguous -- arch is needed
Product: [Fedora] Fedora Reporter: D. Hugh Redelmeier <hugh>
Component: rpmAssignee: Paul Nasrat <nobody+pnasrat>
Status: CLOSED UPSTREAM QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: hugh, nobody+pnasrat
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-04-25 04:36:35 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 D. Hugh Redelmeier 2005-01-14 07:00:30 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Description of problem:
Here's an example from trying to install official FC3 updates.  I
think that there is an error in the hal.spec so that the error message
is correct.  The problem is that it does not enlighten the reader
because NVR isn't enough to uniquely specify the rpm.  I suggest that
these messages also include ARCH.  This is a problem on biarch systems
like x86_64.

# rpm -q --queryformat '%{n}-%{v}-%{r} %{arch}\n' hal
hal-0.4.2-1.FC3 i386
hal-0.4.2-1.FC3 x86_64

# rpm -Fv core3upx86/x86_64/hal-0.4.2-1.FC3.i386.rpm
core3upx86/x86_64/hal-0.4.5-1.FC3.x86_64.rpm
Preparing packages for installation...
        file /usr/share/hal/fdi/20freedesktop/ide-drives.fdi from
install of hal-0.4.5-1.FC3 conflicts with file from package
hal-0.4.2-1.FC3
        file /usr/share/hal/fdi/20freedesktop/usb-zip-drives.fdi from
install of hal-0.4.5-1.FC3 conflicts with file from package
hal-0.4.2-1.FC3
        file /usr/share/man/man8/fstab-sync.8.gz from install of
hal-0.4.5-1.FC3 conflicts with file from package hal-0.4.2-1.FC3


Version-Release number of selected component (if applicable):
RPM version 4.2.1

How reproducible:
Always

Steps to Reproduce:
1. install FC3 for x86_64 with hal in both architectures
2. try to rpm -Fv the updated hal for both architectures
3. read the message
    

Actual Results:  see example in Description

Expected Results:  messages that unambiguously specify the rpm that is
problematic.

Additional info:

RPM mismatches (like the example case) are mysterious and hard to
understand.  Making a message clearer should be a significant help.

Comment 1 Lamont Peterson 2005-05-24 19:06:31 UTC
Another example is the (relatively) recent update of the perl packages;   
because of a packaging error that went undetected for months, AMD64 systems   
had both x86_64 & i386 perl packages even though the 32bit were completely   
unnecessary (I know, I've simplified this description).  Even up2date & yum   
were broken because of the errata packages release to correct the problem.   
   
I would like to suggest that RPM be modified to display the arch by default.    
Preferrably, such a change could be configured in an /etc/rpm/macros (or   
~/.rpmmacros) file.  Then, on x86_64 (ppc64, etc.?) installs, the rpm RPM   
package (did I confuse any of you, there? :) would install an /etc/rpm/macros  
file with the architecture output option turned on (for queries).  
 
Paul <pnasrat> suggested to me that this could be accomplished by 
adding a macro file (in /etc/rpm/) with: 
%_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch} 
 
Paul also pointed out that such a change would/could impact scripts which are 
parsing the output of "rpm -q". 
 
It would also be good to add a note, with examples, to the rpm man page  
showing how things currently work without such information being reported and  
how it will look with the new option turned on.  Obviously, such additions to 
the man page need more thought than I have given here, before being 
implemented. 

Comment 2 Jeff Johnson 2006-04-25 04:36:35 UTC
The %_query_all_fmt macros includes the arch for quite some time now, like a year.