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.
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
