Bug 432799

Summary: Error: libhugetlbfs conflicts with libhugetlbfs-lib < 1.2
Product: Red Hat Enterprise Linux 5 Reporter: James Laska <jlaska>
Component: libhugetlbfsAssignee: Nils Philippsen <nphilipp>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: 5.2CC: jturner
Target Milestone: betaKeywords: Regression
Target Release: ---   
Hardware: powerpc   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2008-0466 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-21 14:38:55 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 James Laska 2008-02-14 13:41:54 UTC
Description of problem:
When upgrading RHEL5.1 to RHEL5.2 via yum dir repo, following dependency
problem pops up:
---> Downloading header for libhugetlbfs-devel to pack into transaction set.
---> Package libhugetlbfs-devel.ppc64 0:1.2-3.el5 set to be updated
---> Downloading header for libhugetlbfs to pack into transaction set.
---> Package libhugetlbfs.ppc 0:1.2-3.el5 set to be updated
---> Downloading header for libhugetlbfs-devel to pack into transaction set.
---> Package libhugetlbfs-devel.ppc 0:1.2-3.el5 set to be updated
--> Processing Conflict: libhugetlbfs conflicts libhugetlbfs-lib < 1.2
--> Processing Conflict: libhugetlbfs conflicts libhugetlbfs-lib < 1.2

Error: libhugetlbfs conflicts with libhugetlbfs-lib < 1.2

Version-Release number of selected component (if applicable):
RHEL5.2-Server-20080212.0 / libhugetlbfs-1.0.1-1.el5

How reproducible:
Always

Additional info:
 
In RHEL-5-Server/U1/ppc we shipped:

/libhugetlbfs-1.0.1-1.el5.ppc.rpm
/libhugetlbfs-devel-1.0.1-1.el5.ppc64.rpm
/libhugetlbfs-devel-1.0.1-1.el5.ppc.rpm
/libhugetlbfs-lib-1.0.1-1.el5.ppc64.rpm
/libhugetlbfs-lib-1.0.1-1.el5.ppc.rpm

In RHEL5.2-Server-20080212.0 we are shipping:

/libhugetlbfs-1.2-3.el5.ppc.rpm
/libhugetlbfs-devel-1.2-3.el5.ppc64.rpm
/libhugetlbfs-devel-1.2-3.el5.ppc.rpm

I don't think we can drop a -lib package can we?  If we want to, libhugetlbfs
would need to %Provide libhugetlbfs-lib?

Comment 2 Nils Philippsen 2008-02-14 14:29:08 UTC
Seems to be a compose problem to me, i.e. 5.2 should ship libhugetlbfs in both
ppc64 and ppc since it contains the library now. I don't think "Provides
libhugetlbfs-lib" is strictly necessary, as a) the library soname would be
provided automatically and b) it's usually used via an LD_PRELOAD mechanism (if
I understand upstream correctly). Whom should I contact so libhugetlbfs gets
shipped in both arches?

Some background to the packaging: the old version contained a daemon in the base
package, libraries where in -lib. The daemon isn't necessary anymore so I
decided to move the libraries into libhugetlbfs.

Comment 3 Dennis Gregorovic 2008-02-14 16:50:50 UTC
Nils, could you modify libhugetlbfs-devel.ppc64 so that it depended on one of
the 64bit libraries provided by libhugetlbfs.ppc64?  That would cause
libhugetlbfs.ppc64 to get pulled in automatically during dependency resolution.  

Comment 4 James Laska 2008-02-14 16:51:43 UTC
Thanks Nils ... sounds like we may have 2 issues then after reading your comment.

1) Customer upgrades from U[01] -> U2.

If we once shipped libhugetlbfs-lib, but now we don't  ... we need to provide a
path through yum such that the customer can upgrade from a previous release. 
Right now I believe that's failing due to the dropped -lib packages.  I think we
can either add them back, or add %provides or %obsoletes such that the 5.2
libhugetlbfs package properly removes the no longer needed -lib package.

2) re: ppc vs ppc64

The 5.2 compose matches the 5.1 compose in terms of shipping the ppc packages,
and *only* the -devel ppc64 package.  Is that not correct?

Comment 5 Nils Philippsen 2008-02-14 17:03:29 UTC
(In reply to comment #3)
> Nils, could you modify libhugetlbfs-devel.ppc64 so that it depended on one of
> the 64bit libraries provided by libhugetlbfs.ppc64?  That would cause
> libhugetlbfs.ppc64 to get pulled in automatically during dependency resolution.  

I could add "Provides: %{name}-%{arch} = %{version}-%{release}" to the base
package and let the devel packages depend on that.

(In reply to comment #4)
> Thanks Nils ... sounds like we may have 2 issues then after reading your comment.
> 
> 1) Customer upgrades from U[01] -> U2.
> 
> If we once shipped libhugetlbfs-lib, but now we don't  ... we need to provide a
> path through yum such that the customer can upgrade from a previous release. 
> Right now I believe that's failing due to the dropped -lib packages.  I think we
> can either add them back, or add %provides or %obsoletes such that the 5.2
> libhugetlbfs package properly removes the no longer needed -lib package.

Funny, I thought that the package already did that:

[... in the base package ...]
Obsoletes: libhugetlbfs-lib < 1.2
Conflicts: libhugetlbfs-lib < 1.2
[...]

> 2) re: ppc vs ppc64
> 
> The 5.2 compose matches the 5.1 compose in terms of shipping the ppc packages,
> and *only* the -devel ppc64 package.  Is that not correct?

I see 32bit and 64bit devel in comment #0, but only the 64bit base. Seems like
Dennis' proposal would help here.

Comment 6 James Laska 2008-02-14 17:21:40 UTC
(In reply to comment #5)
> Funny, I thought that the package already did that:
> 
> [... in the base package ...]
> Obsoletes: libhugetlbfs-lib < 1.2
> Conflicts: libhugetlbfs-lib < 1.2
> [...]

Oops yeah, I missed that.  Could that be confusing yum a bit ... meaning, it's
doing what we've asked and saying that installing libhugetlbfs will conflict
with -lib.

If we remove the %conflict and just leave the %obsoletes?

Comment 7 Nils Philippsen 2008-02-14 18:28:30 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Funny, I thought that the package already did that:
> > 
> > [... in the base package ...]
> > Obsoletes: libhugetlbfs-lib < 1.2
> > Conflicts: libhugetlbfs-lib < 1.2
> > [...]
> 
> Oops yeah, I missed that.  Could that be confusing yum a bit ... meaning, it's
> doing what we've asked and saying that installing libhugetlbfs will conflict
> with -lib.

The problem seems to stem from that the base libhugetlbfs package is only
available in 64bit (so the 32bit base pkg obsoleting the old 32bit -lib package
doesn't happen). My bet is that we just need to get the 32bit base pkg in the
collection and the upgrade should work, any arch-specific Provides/Requires is
just icing on top.

> If we remove the %conflict and just leave the %obsoletes?

Most definitely not ;-). I positively don't want anybody running around with the
new 64bit version on and the old 32bit version of the packages simultaneously.

Comment 17 errata-xmlrpc 2008-05-21 14:38:55 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0466.html