Bug 432799 - Error: libhugetlbfs conflicts with libhugetlbfs-lib < 1.2
Error: libhugetlbfs conflicts with libhugetlbfs-lib < 1.2
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libhugetlbfs (Show other bugs)
5.2
powerpc Linux
low Severity medium
: beta
: ---
Assigned To: Nils Philippsen
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-14 08:41 EST by James Laska
Modified: 2013-09-02 02:24 EDT (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2008-0466
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 10:38:55 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 James Laska 2008-02-14 08:41:54 EST
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 09:29:08 EST
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 11:50:50 EST
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 11:51:43 EST
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 12:03:29 EST
(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 12:21:40 EST
(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 13:28:30 EST
(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 10:38:55 EDT
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

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