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
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
Daniel, please answer comment #2. Also please give a detailed list of which packages+arch go into which group in comps. Thanks!
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.
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)
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.
(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.
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?
(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.
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.
(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.
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