Bug 453787 - multilib packages for OFED group
multilib packages for OFED group
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: comps (Show other bugs)
4.7
All Linux
medium Severity medium
: rc
: ---
Assigned To: Daniel Mach
Alexander Todorov
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-02 10:55 EDT by Daniel Mach
Modified: 2008-07-24 15:07 EDT (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2008-0655
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-24 15:07:26 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 Daniel Mach 2008-07-02 10:55:36 EDT
I asked Doug Ledford to review rpm list of latest snapshot and this is the
summary of OFED packages which need to be multilib:

dapl-static.ppc64 -> ppc
libcxgb3 -> multilib
libcxgb3-static.ppc64 -> ppc
libehca-static.ppc64 -> ppc
libibcm-static.ppc64 -> ppc
libibcommon-static.ppc64 -> ppc
libibmad-static.ppc64 -> ppc
libibumad-static.ppc64 -> ppc
libibverbs-static.ppc64 -> ppc
libmlx4 -> multilib
libmlx4-static.ppc64 -> ppc
libmthca-static.ppc64 -> ppc
libnes -> multilib
libnes-static.ppc64 -> ppc
librdmacm-static.ppc64 -> ppc
opensm-static.ppc64 -> ppc
Comment 2 Mike McLean 2008-07-02 11:50:37 EDT
Daniel, you referred to these as "packages which need to be multilib." Could you
explain your notation above please? What precisely is meant by

packagename.ppc64 -> ppc

as opposed to

packagename -> multilib
Comment 4 Alexander Todorov 2008-07-02 14:08:08 EDT
Daniel,
please answer comment #2. Also please give a detailed list of which
packages+arch go into which group in comps.

Thanks!
Comment 8 Mike McLean 2008-07-02 15:44:48 EDT
The term "single-arch multilib" is confusing at best. A better term would be
"64-bit override." A clearer representation would be:

packagename - ppc64 only

Frankly, I'm *VERY* wary of making these sorts of changes this late in the game.
This should have been done before Beta. Multilib changes can have unexpected
side effects that do not always show up in our automated tests, /particularly/
on ppc.

If we can possibly push this to 4.8, I'd feel much better.
Comment 9 Daniel Mach 2008-07-02 15:57:11 EDT
I should more clear next time, since the list I mentioned in comment#7 contains
only new packages for those trees.
Sorry for confusion.

ppc trees should contain:
dapl-static (ppc + ppc64)
libcxgb3 (ppc + ppc64)
libcxgb3-static (ppc + ppc64)
libehca-static (ppc + ppc64)
libibcm-static (ppc + ppc64)
libibcommon-static (ppc + ppc64)
libibmad-static (ppc + ppc64)
libibumad-static (ppc + ppc64)
libibverbs-static (ppc + ppc64)
libmlx4 (ppc + ppc64)
libmlx4-static (ppc + ppc64)
libmthca-static (ppc + ppc64)
libnes (ppc + ppc64)
libnes-static (ppc + ppc64)
librdmacm-static (ppc + ppc64)
opensm-static (ppc + ppc64)

x86_64 trees should contain:
libcxgb3 (i386 + x86_64)
libmlx4 (i386 + x86_64)
libnes (i386 + x86_64)
Comment 10 Doug Ledford 2008-07-02 16:27:00 EDT
If you exclude all the -static changes which can easily be put off until 4.8,
you are left with this:

libcxgb3 -> multilib
libmlx4 -> multilib
libnes -> multilib

Now, as long as setting these to normal multilib *also* results in them
including both ppc and ppc64 on ppc64 machines (as opposed to just overriding
ppc with ppc64 and not including both), then we are done.  If it's the later,
then you need an override to get ppc64 to include both versions of these libs
instead of just the ppc64 one.
Comment 11 Alexander Todorov 2008-07-03 06:43:52 EDT
(In reply to comment #9)
> ppc trees should contain:
... skip ...

> x86_64 trees should contain:
... skip ...

What about ia64 and s390x trees?


Also since this is assigned to comps please provide the list from comment #9
including comps group in which packages will be listed (ofed,
compat-arch-support, other?) or none if they'll not be listed in comps.
Comment 12 Daniel Mach 2008-07-03 07:11:37 EDT
We had a discoussion about this bug on IRC.
Conclusion was to add libcxgb3, libmlx and libnes to compat-arch-support group
and verify results when compose is finished.

I added following lines to compat-arch-support group:
<packagereq type="default">libcxgb3</packagereq>
<packagereq type="default">libmlx4</packagereq>
<packagereq type="default">libnes</packagereq>

RPM lists were verified by me and Doug Ledford (see ticket for RC tracking).
Since I asked Doug for this file list, I believe it's ok.

Doug, can you please confirm that there's no need include 32bit libcxgb3, libmlx
and libnes rpms in ia64 and s390x?
Comment 14 Doug Ledford 2008-07-03 08:36:00 EDT
(In reply to comment #12)
> We had a discoussion about this bug on IRC.
> Conclusion was to add libcxgb3, libmlx and libnes to compat-arch-support group
> and verify results when compose is finished.
> 
> I added following lines to compat-arch-support group:
> <packagereq type="default">libcxgb3</packagereq>
> <packagereq type="default">libmlx4</packagereq>
> <packagereq type="default">libnes</packagereq>
> 
> RPM lists were verified by me and Doug Ledford (see ticket for RC tracking).
> Since I asked Doug for this file list, I believe it's ok.
> 
> Doug, can you please confirm that there's no need include 32bit libcxgb3, libmlx
> and libnes rpms in ia64 and s390x?

Yes, I can confirm that.

Comment 15 Mike McLean 2008-07-03 13:51:50 EDT
Ok, based on comment#12 we're still making multilib changes (albeit less of
them). We are still taking a risk then, and should carefully test this.

Daniel, after you run the compose for this, please compare that tree to the
previous ones and verify the multlib changes. You need to check:
  1) that the requested packages are in fact multilib
  2) that no additional packages became multilib through dependencies

If when checking #2, you find that additional packages did become multilib, then
we will need to verify that they are multilib-safe, particularly on ppc.
Comment 19 Daniel Mach 2008-07-07 13:05:59 EDT
(In reply to comment #15)
> Daniel, after you run the compose for this, please compare that tree to the
> previous ones and verify the multlib changes. You need to check:
>   1) that the requested packages are in fact multilib
>   2) that no additional packages became multilib through dependencies
> 
> If when checking #2, you find that additional packages did become multilib, then
> we will need to verify that they are multilib-safe, particularly on ppc.
This has been already verified after the compose by Doug and me.
There are just three new rpms each tree (ppc and x86_64).
No missing rpms or additional rpms pulled via multilib deps.
Comment 26 errata-xmlrpc 2008-07-24 15:07:26 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 therefore 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-0655.html

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