On Thu, Nov 27, 2008 at 10:07 AM, Duncan <[EMAIL PROTECTED]> wrote:
> Tonko Mulder <[EMAIL PROTECTED]> posted
> [EMAIL PROTECTED], excerpted below, on Thu, 27 Nov 2008
> 06:35:20 +0100:
>
>> [EMAIL PROTECTED] ~ $ 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
