[gentoo-amd64] Re: Re: Re: Re: file type not allowed in /usr/lib

[Duncan]

Simon Stelling posted <42F9FD31.4050307@g.o>, excerpted below,  on
Wed, 10 Aug 2005 15:12:17 +0200:

> Well, the problem is, even if you have two different directories for each
> bitness, the binaries will still collide, because of $PATH: How do you
> decide whether you want the 32bit or 64bit player? There's no real
> solution other than having suffixes like e.g. mplayer32 and mplayer64. You
> could reset PATH each time you launch a binary of other bitness, but
> that's just an ugly workaround and it may not always do what you want. So
> you have to use suffixes. But then, you don't need two directories, as the
> binaries won't collide anymore... Additionally, what do you do about
> scripts? PATH doesn't work there, and so you'd have to first edit the
> #!-line before executing it.

As I've imagined it here, altho I admit there are likely huge holes in it
that I'm not aware of given I haven't had to be concerned with the actual
implementation process...

$PATH would include $PREFDIR:$DEFAULTBIN:$SECONDARYBIN.  $DEFAULTBIN would
be the normal system default, presumably bin64.  $PREFDIR would contain
symlinks to individual executables in $SECONDARYBIN, where they are
preferred over those in $DEFAULTBIN, allowing a system default, with
individual application defaults differing from the system default, as
necessary.

In addition, $PREFDIR could contain suffixed or otherwise identified
symlinks to both bitness versions specifically.  Thus, applications could
be referred to by general name to get the locally preferred default in
$PREFDIR, suffixed name to get the specific bitness version, or by
absolute path, getting the specific bitness version or the locally
preferred default as specified in $PREFDIR, as desired/appropriate.

There'd be a similar config dir setup, with a system default config, and a
secondary config dir for those apps that are configured differently
between the bitnesses.  Again, a general symlink dir could be used to
coordinate things, or compliant apps could do the usual mult-dir search
until they found a config, searching first their specific bitness
config-dir then the system default config-dir.

Presumably, the suffixed symlinks would be created in $PREFDIR at
installation.  There's be a helper script similar to *-config that could
be used to select between them, or the sysadmin could set the symlinks
manually if desired.

Each distribution could set up its own system, but again, LSB/FHS or the
like standardization would be a pretty big benefit, here, such that at
least the standard dir locations to search were agreed.  Some
distributions would then go with the more or less simple symlink
infrastructure as outlined above, others may replace the symlinks with
more complex wrapper scripts that would "do the right thing" for that
specific distribution.

I don't see scripts as being a huge problem, particularly if the dirs were
standardized.  Those scripts that needed specific bitness versions would
call them, presumably by suffix; those that didn't would call the
unsuffixed version, which would automatically find the appropriate
default, either picking it up from $PREFDIR, or falling thru to the global
system default in $DEFAULTBIN if a prefdir symlink or wrapper wasn't
defined, presuming of course, that path was set appropriately.  Where such
path presumptions couldn't be relied upon, for security or other reasons,
absolute paths could be used, using the already common in scripts
if-executable type tests except in the case of the #! lines, which would
still need tweaked by distributions or sysadmins in some instances.

Like I said, there's probably huge holes in all that, due to the fact that
I've never been in the position of someone having to worry about such
implementation details at a distribution level...


> On the other hand, multilib will never be a permanent solution, I see it
> as a nice way to keep compatibility with old stuff, but as soon as
> companies are starting to provide 64bit binaries, it will slowly
> disappear from amd64's sight.
>
> So the final question is: Is it really worth the effort?

Well...  I suppose it depends on just how "slow" reality defines "slowly"
to be.

We have the precedent of the 16 -> 32-bit transition.  I'm not familiar
with *ix from back then, but know at least on the proprietaryware aka MS
side, the practical transition took a decade or longer, and there are
still 16-bit binaries in use today, altho very often run under software,
if not hardware, emulation.  Think about how long it was before 32-bit
virtual 386 mode became common.  Then consider how much more society
depends on 32-bit x86 today, as compared to 16-bit x86 back then, and the
fact that 32-bit is far closer to "good enough" for most folks using it
today than 16-bit was back then -- the improvements are more incremental
now, because the percentage improvement on the established base is
smaller, even if the improvement in the absolute sense is the same or
even greater.

Given that, I think a decade is a realistic estimate.  Admittedly, there
are quite a few different factors this time around, the far higher degree
of computer use in society, and the "good enough" factor, on the one hand,
against the possible paradigm shift to FLOSS, and what that might mean to
the whole debate, on the other.  Still, a decade seems reasonable, and
that's a /very/ long time, in computer evolution terms.

Then there's the whole question as to where to start counting.  Where is
day zero in that decade?  I'd contend that it's in the past, certainly,
but do we call the introduction of the Opteron day zero, or do we call the
introduction on the desktop, the Athlon 64, day zero, or do we call
Intel's introduction day zero?  Are we already a couple years into that
decade, or only a few months?  If it's a couple years, you are correct, by
the time we get multilib fully implemented, we may have already passed the
half-way mark, and the actual need for multilib, let alone multibin, will
be on the decline.  If day zero is taken to be when the Intel version
actually became available on the streets, it's still fairly early in the
game, yet, and it may well be worthwhile considering multibin, even now,
particularly since the bulk switch from x86(32) definitely remains ahead,
and if the decade timeline proves optimistic.  Also throw into that the
whole proprietary/open thing.  Certainly, those with more freedom to
modify the software they run, aren't going to be needing such drastic
compatibility measures as those without.  (It's for that reason that the
entire debate is mostly an intellectual exercise, for me, as I personally
come down far closer to the freedom end of things, than, say, those
willing to run even proprietary video drivers and games, let alone entire
proprietary OSs, and most of the apps on them.)

So... I'm /definitely/ of the opinion that multilib is worthwhile.  I
think multibin /could///would/ have been as well, were the momentum for it
at the same level as multilib is today.  However, I think most will agree
that it's definitely rather late to start worrying about multibin at this
point, however nice it /might/ have been to have it.

IOW, as a practical matter, I don't see multilib disappearing from sight
any time soon.  If anything, its importance is likely to increase
DRAMATICALLY over the next few years (three at least), as the mainline x86
computing public switches over, bringing with them all that 32-bit
binary-only cruft they'll invariably have.  That is, after all, one of the
big reasons x86_64 has become the success it has, even in the face of
Intel's pushing ia64 as the "preferred" alternative.  By 2008,
multilib importance may begin to decrease, tho I don't see it
dropping to something that can really be ignored (unless deliberately so),
until 2010 at the earliest.

Then again, what's this "Joe Blow" know? =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list