Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Hmm? I have i686 and x86_64 packages installed at the same time on Fedora and I remember RHEL 5 being the same. I haven't played with RHEL 6 enough to remember.
Quotes of the week
Posted Jun 14, 2012 23:50 UTC (Thu) by jschrod (subscriber, #1646)
On an i686 installation, no x86_64 kernel package is available, like it is in Debian. "yum list 'kernel*'" tells so.
Of course, you can always create your own completely-self-made-up package list and use Anaconda or AutoYast or such. But this is what I called "roll-your-own installation" above, then you create a spin. It is not an installation mode that is supported by a distribution out-of-the box -- which is what I was asking for.
I don't deny that it ain't possible; after all, one can also always roll one's own kernel and install that. I hinted to the fact that such an installation mode is not widespread because it is *not a mode commonly offered by distributions*.
Posted Jun 17, 2012 8:29 UTC (Sun) by drago01 (subscriber, #50715)
That's just not true.
You can install those just fine ... they won't conflict because the shared libraries go into different directories (lib vs lib64). Which is the whole point of multilib. Binaries in both packages won't conflict either because rpm has a concept of "coloring" which means if you install foo.i686 and foo.x86_64 and both ship /usr/bin/foo it *wont* conflict. /usr/bin/foo will just be the x86_64 one.
Name examples of what you mean. You might just have hit some kind of packing bug for a specific library but they are designed to not conflict and it works fine for me here.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds