Red Hat Bugzilla – Bug 205235
No way to put 64bit _applications_ to the ISO
Last modified: 2013-01-09 23:03:31 EST
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
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
(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
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.