Bug 432799
Summary: | Error: libhugetlbfs conflicts with libhugetlbfs-lib < 1.2 | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | James Laska <jlaska> |
Component: | libhugetlbfs | Assignee: | Nils Philippsen <nphilipp> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 5.2 | CC: | jturner |
Target Milestone: | beta | Keywords: | 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
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. 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. 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? (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. (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? (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. 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 |