Hide Forgot
Imagine: for a package foo, there are two binary packages: foo-1.2-3.ppc.rpm and foo-1.2-3.ppc64.rpm. Which of them get collected for the ppc iso? 1) For most applications, the 32bit version is quicker, and thus preferred. The ppc64.rpm would never have been used: consequently, it is not included in the iso. 2) For some *libraries*, the 64bit version can also be useful, so both rpms are included in the iso, and both get installed (if the machine is 64bit). These are so called "multilib" packages. 3) There are certain applications for which the 64bit version should be preferred, and the 32bit versions should be used only on 32bit systems. Thus both rpms should be included on the iso, but they cannot be installed simultaneously. (An example of such a package is gdb or frysk.) How do I achieve this?
You would get release-engineering to add them to the multilib list that is maintained for things that are multilib but don't have a -devel package. I've added gdb as there is both a ppc and ppc64 package. However as we spoke about before, there is no ppc package for frysk, so I'm reluctant to add it to the 'multilib' list when it really isn't multilib.
I hope the term 'multilib' does not in this case mean that anaconda will try to install both. (gdb.ppc conflicts with gdb.ppc64, and frysk.ppc will conflict with frysk.ppc64.)
Yes, it will. Thats the point of multilib, they can both be installed at the same time. If they conflict, they can't be listed as multilib.
OK, then neither gdb nor frysk may be listed as multilib. And we have to get back to the beginning: the release process has to be enehanced to support 64bit _applications_. ("multilib" is not what we want here.) (I admit the original description of the bug is too wordy, but I was not able to do better.)
I'm not entirely sure how Anaconda (yum) would treat this when there is both .i386 and .x86_64 packages in the repo. By default it installs both that are available. I'm reassigning to anaconda for now, as this is more than a matter of just putting the package in the tree.
Ermm, gdb doesn't conflict between ppc and ppc64 -- the fact that they have common binaries is fine (the common binary files are ELF32 and ELF64, so rpm will properly prefer the ELF64 binary and only put it on the disk) The only time there's a problem is if there are common files which _aren't_ architecture specific. Do you have anything like htis?
Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer test releases. We're cleaning up the bug database and making sure important bug reports filed against these test releases don't get lost. It would be helpful if you could test this issue with a released version of Fedora or with the latest development / test release. Thanks for your help and for your patience. [This is a bulk message for all open FC5/FC6 test release bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
requested by Jams Antill
I did not understand multilib when I filed this bug. I think it can be closed now.