[CentOS] Is Biarch with 6.x now dead?

Wed Dec 28 20:32:28 UTC 2011
Johnny Hughes <johnny at centos.org>

On 12/28/2011 12:53 PM, Michael Lampe wrote:
> Johnny Hughes wrote:
>> There is a variable in yum.conf called multilib_policy ...
>> The default in CentOS 5 is all ... the default in CentOS 6 is best.
> Ah, ok. Part of my playing around with 6.2 ist finding all the 
> differences with respect to 5.x. ;)
>> I can tell you that I would personally use something like mock to build
>> or 32-bit items in at least a clean chroot when building/compiling 32
>> bit things on a 64-bit machine.  But to each their own.
> I'm somehow confused with all of you loathing biarch so much. I can 
> partly understand this from a packagers point of view, but as an end user?
> What you get at the end if you install both 32-bit and 64-bit packages 
> is the 32-bit stuff in (basically) /usr/lib. Otherwise nothing changes. 
> So the added stuff _is_ cleanly separated from the rest of the system.
> The kernel runs 32-bit and 64-bit programs anyway, gcc has '-m32' (you 
> cannot even get rid of this), and all you you need to compile an run 
> 32-bit programs is the extra stuff in /usr/lib. (The include/doc/etc. 
> files which are in both packages _must_ be identical, that's checked.)

When you build things, *-devel files are used.  If you have extra stuff
(any extra stuff) in the build root, then the configure scripts can find
it and link against it since there are many optional things that are
searched for in the configure scripts.

This is true if you have curses installed (as an example) ... some
program's configure script will find that and link against it.  Now,
every time you want to run that program, you need to have curses installed.

It is therefore very important to have a very clean build root, with
only the absolute minimum amount of packages (or if you like, the
minimum libraries and headers) installed that are required to build the
package.  That way you control what is linked against.

If you have the 32bit headers in /lib/ (instead of in /lib64/) ... and
if the some crazy configure script finds it and there and includes it,
what does that do to the build?

This is why Red Hat uses mock to build packages.  It builds a clean root
to build packages.

It also is why OBS (open build system from opensuse) builds a VM or a
buildroot for each individual package, installing only the things needed
to build against.

> All the Unix systems from the old days (Irix, Solaris, AIX, ...) had 
> this long before Linux saw 64 bits.
> I like this feature very much, I and several others are using it on 5.x 
> for years now, and nobody ever complained.
> The only problems I ever had were with you, Dear Packagers/Rebuilders. 
> Sometimes you forgot the updated 32-bit package from the x64 updates 
> repo, an in one case they were even really clashing in an unallowed way. 
> Your fault again. :)
> So: what's the beef?

If you are on a machine that is not building things, then having the
32-bit software also on there is fine ... if you need it.

Now, personally, I don't want anything on my machines that are not
required to make them work.  If some script kiddie needs /lib/ld-2.12.so
for his hacker script to work and I only have /lib64/* stuff then that
is good as far as I am concerned.

I don't want things on any of my machines unless it is required ... So,
unless I need X and Gnome, it is not installed.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20111228/b65e2d38/attachment-0005.sig>