Public SourceMage Discussion List

[sergey AT optimaltec.com]

OK, third time: I strongly object to having support for multilib systems in
SMGL. We're burdened as it is with custom patches and fixes, this will be one
more *major* kludge. If my capacity as a grimoire sections maintainer allows
this, I'd like to call a vote to ban this approach in SMGL.

Until there's a decent design that guarantees not only choice, but stability,
I'm against it. For things like multilib support, PAM, SELinux, etc., we have
to understand that it is an all-or-nothing approach most of the time. E.g., 
you
you choose multilib, you have to make sure this option is uniform across 
glibc,
gcc, g++, binutils, etc. Then you'll have a multilib environment. But now,
suppose you want 32-bit Firefox in your all-64-bit system, to use the Flash
plug-in. How do you make sure all the dependencies Firefox has are actually
built for 32 bits? Or are you going to require user to answer one more 
question
for every new spell, the one that few will care to understand and even fewer
will answer uniformly (same answer to same question). By the time we're done
implementing this feature, Macromedia will release a 64-bit plugin and
everything would be alright. 64-bit compatibility is a major push, both driver
writers and software companies recognize it, and many are already prepared,
e.g. Sun and Oracle.

If no such design exists in sorcery, supporting cross-cutting options such as
multilib, multiple versions of the same spell, etc., are extremely difficult
and produce virtually no value to both system administrators and users.

Sergey.

Quoting Seth Alan Woolley <seth AT positivism.org>:

>
> You didn't see much because you had the Great Big Symlink.  Yeah, that's
> great for single-arch.  Anything else, and it's potential doom (although
> I suppose you could leave the GBS and use /lib and /ilb64 for 64-bit and
> /lib32 for 32-bit).
>
> Very few spells happen to install to /lib64 by default.  My patches just
> clean up a few.  Perl wasn't even looking in /lib64 for glibc, and is
> actually improved by installing to /lib natively.  My patch for perl
> just makes it look in /lib64 instead.  Granted, the GB /lib64 to
> /lib Symlink fixes that, but why not make perl flexible enough to be
> used on multilib systems?
>
> I'm at the same time helping make it so you can have separate
> directories with different binaries in /lib and /lib64 or /lib and
> /lib32 so that you can have a decent multilib system later.  In order to
> do this though the Great Big Symlink would be best to go.