Re: [gentoo-amd64] Re: Multilib or not?

[Tonko]

On Thu, Nov 27, 2008 at 10:07 AM, Duncan <1i5t5.duncan@×××.net> wrote:
> Tonko Mulder <tonko.mulder@×××××.com> posted
> 1227764120.6272.13.camel@Gaius, excerpted below, on  Thu, 27 Nov 2008
> 06:35:20 +0100:
>
>> tonko@Gaius ~ $ ls -dl /lib /lib64
>> drwxr-xr-x  4 root root   46 nov 26 21:32 /lib
>> drwxr-xr-x 10 root root 8192 nov 27 06:08 /lib64
>
> OK, that's the problem, I believe.  I too tried separate dirs, just to
> see how it would go, and had problems.
>
> It seems a few packages, probably lvm2 among them, use /lib some of the
> time and /${LIBDIR} (which on amd64 equals /lib64) some of the time.  In
> particular, a couple packages I looked at (and lvm2 was probably one of
> them but I've forgotten by this point) would install to one but the
> initscripts would try to use the other.
>
> Basically, they expect the usual Gentoo config which has a symlink one
> way or the other (it doesn't particularly matter which way, various
> Gentoo/amd64 stage releases have reversed each other).  If each one is
> its own dir, they fail, because they install to one and try to use the
> other, at least part of the time.
>
> So, preferably from single-user-mode or elsewise when there's nothing
> that might crash due to their files temporarily moving out from under
> them, move everything from one into the other, then delete the empty one
> and create a symlink from it to the other.
>
This seemed to have worked, as my lvm2 script starts nicely :)
I thought there a warning during boot-time but can't find in my rc.log

So.. cheers :)
> As I said, which way you go shouldn't really matter.  To some extent, it
> depends on which one you think is the "proper" $LIBDIR in a 64-bit-only
> system.  If you think it's /lib because that's what you're used to using
> on 32-bit or simply because it's shorter to type, make /lib64 the symlink
> pointing at /lib.  If you (like me) like the 64 specified, even in the
> absence of any 32-bit, or if you want to stick closest to the LSB/FHS
> standard [1] for amd64/x86_64, you'll make /lib the symlink pointed at /
> lib64.  In either case, if you ever decide you need to, you can always
> reverse yourself later.
>
> Technically, those rcscript/addons/*.sh do indeed belong in /lib since
> they're shell scripts and as such are bitness independent [1, again].
> However, I expect what's happening is that the initscripts are using
> /${LIBDIR} for some of the calls, and on amd64 that's /lib64, so that's
> where the initscripts are trying to find them at least for those calls.
> As long as /lib and /lib64 ultimately resolve to the same place, it
> doesn't matter, but if they are both real directories, BAD THINGS (tm)
> happen.
>
> ---
> [1] As I understand it, the FHS, File Hierarchy Standard, part of the
> LSB, is arguably inconsistent with itself in regard to $LIBDIR.  Non-
> native-code such as scripts and bytecode compiled stuff (python/perl/
> java), where every arch gets the same files, pretty consistently belongs
> in /lib and /usr/lib.  But there's an inconsistency with where 64-bit
> native-binary-code libraries go.  On ia64 (itanic/itanium), 64-bit really
> is seriously dominant and was intended to fully supplant 32-bit
> immediately.  It gets /lib.  32-bit is a distant also-ran that must be
> content with (IIRC) /lib32.
>
> On amd64/x86_64, the considerations were much different.  Unlike ia64,
> amd64 is real hardware dual-bitness and it was apparent even before it
> came out (due to the flatlining of itanic, compared to predictions and
> hype, at least) that many/most people wanted to be able to run both 32-
> bit and 64-bit code on the same system at the same time.  Due to the
> dominance of existing 32-bit code, it was far easier to let it take /lib
> so 32-bit packages wouldn't need any changes at all.  Since the process
> of making 64-bit packages already included porting the code, making sure
> it was 64-bit safe, etc, adding the comparatively trivial task of having
> it use /lib64 by default wasn't that big a deal, especially compared to
> being forced to update all those otherwise perfectly fine 32-bit packages
> to use something other than /lib.  So unlike ia64, amd64/x86_64 let 32-
> bit have /lib and standardized on /lib64 for 64-bit code.  While this was
> designed to let 32-bit and 64-bit exist at least semi-happily
> side-by-side, once the standard was established it made little sense to
> change it for 64-bit-only systems, so /lib64 it remains.
>
> Of course then there's the whole (/usr)/libexec thing.  The idea there is
> that $LIBDIR (whether just lib or lib32/lib64) is for libraries and
> $BINDIR is for executables designed to be run directly, but where are
> executables really only designed to be called from other executables to
> be placed?  You don't want them in $BINDIR, since that's in $PATH and
> thus users will see it with tab-completion and the like, and these
> executables aren't designed to be run from the command line or otherwise
> (from a WM menu) directly invoked by the user.  Traditionally these went
> in lib as well, generally in package level subdirs thereof, but some
> people weren't happy with that and with the FHS standard, they decided
> libexec was a more suitable standard location.  So most systems now have
> a libexec, but this bit of the standard isn't so well known and many
> packages were already using lib by the time the standard came about and
> didn't want to hassle the change, so only a relatively few packages
> actually use libexec, despite what the standard says.  Also, I've never
> seen a root level /libexec, only /usr/libexec, so apparently it's only
> for binaries not needed during early boot, only after /usr is mounted.
>
> That's the story as I understand it for x86, ia64, and amd64/x86_64.  I
> really have no idea how the other archs, ppc and sparc at least of which
> I know have both 32-bit and 64-bit variants, handle it, or what their FHS
> spec might be.
>
> --
> 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
>
>
>



-- 
Tonko