[gentoo-amd64] Re: Emerge libraries in /usr/lib32 too

[Duncan]

Richard Freeman <rich@××××××××××××××.net> posted
462CEC63.2030705@××××××××××××××.net, excerpted below, on  Mon, 23 Apr 2007
13:26:59 -0400:

> Regis Decamps wrote:
>>
>> What do you mean by "expand" the tarball? If I merge the tarball in the
>> / of my main amd64 system, then I'll lose my amd64 lib, won't I? On my
>> system /use/lib points to /usr/lib64.
>
> Yup.  I was thinking about stuff that just doesn't work at all 64-bit.
> This wouldn't work for multilib.  It really is a bit of a hack that
> isn't the kind of fix I'd package up for anybody but myself...

Both of you are aware that portage binpkgs are simply bz2'ed tarballs 
(thus the tbz2 extention) of the various files composing the installed 
package, with the ebuild and a bit of additional metadata tacked onto the 
end, right?

Thus, one can simply extract the package tarball as one would a normal 
tarball, using the appropriate tar switches (or the equivalent GUI 
functionality) to ensure that it doesn't extract directly over /, thus 
overwriting a 64-bit version.  tar will warn about extra data on the end 
-- the ebuild and metadata tacked on -- but it still extracts just fine.

In fact, that's basically what the emergency rescue procedure is for 
getting a working portage if it breaks.  You procure a binpkg (they used 
to have one for download, but quickpkg-ing up the latest Gentoo release 
version out of a stage tarball works as well, and I'm not sure if they 
maintain the emergency portage download itself any more, since it could 
just as easily be python or some other portage dependency that's broken), 
then extract it over the "dead" version on the normal filesystem.  
(Please backup config files it'll overwrite first, or simply don't 
replace them if you are extracting and placing files manually.)  After 
that, you should have a working portage, but its database will still 
think it has the version that broke merged, so you then merge a known 
working version again, thus getting the database in sync with what's 
actually merged once again.

Since I use FEATURES=buildpkg and have for some time, I have a basically 
complete history of packages, often several versions (using eclean, from 
gentoolkit, once in awhile to clean out the old ones), stored in my 
$PKGDIR.  Thus, if something breaks, I either use portage itself to roll 
back to an earlier version, or extract the tarball manually, if necessary.

Actually, it's also quite useful to have the packages around otherwise as 
well.  If I want to extract a single file from an older version, for 
whatever reason, it's easy to do, as it is to simply compare how configs 
or included files might have changed from version to version.  Both are 
occasionally quite useful indeed for bug tracing, in addition to the 
standard sysadmin role package rollback feature.  FEATURES=buildpkg is 
therefore one of my favorite "Gentoo poweradmin" tricks, almost a secret, 
as IMO the handbook (last I checked anyway) doesn't say /nearly/ enough 
about how truly useful this feature can be, and how one can really make 
use of it!

>> Should /usr/lib point to /usr/lib32 instead? I think it should in the
>> future, but I was not aware the Gentoo layout was LSB (Linux standard
>> base) compliant already. Is it?
>>
>>
> You must be new here...  :)  It used to point to lib32 and a lot of
> sweat and tears went into changing it to the way it is now...  I don't
> profess to be an LSB expert...

Actually... AFAIK the LSB says for AMD64, lib should be 32-bit (plus arch-
neutral stuff), while lib64 is 64-bit.  However, Gentoo/amd64 made its 
original choice before that standard existed, and was originally 
implemented more like ia64 (Itanium), where lib is 64-bit, and lib32 is 
32-bit.  The LSB reasoning being that on ia64, 64-bit is the only true 
native bitness, 32-bit being emulated, so lib gets the native.  On x86_64 
aka amd64, both bitnesses are truly hardware-native, so the new bitness, 
64-bit, gets the new location, lib64, while the old 32-bit gets to keep 
lib for legacy reasons.  The original Gentoo reasoning being that 64-bit 
will ultimately be the emphasized bitness, with legacy 32-bit being less 
of an issue as time goes on, so 64-bit should get the native bitness 
location in lib.  (Gentoo 32-bit was originally in emul/lib32, or some 
such, I've forgotten.)

However, when LSB went the other way, since there was no serious Gentoo 
reason to do otherwise, Gentoo/amd64 started trying to move toward the 
standard.  Basically, we've moved 64-bit to lib64, while keeping 32-bit 
in lib32.  On Gentoo/amd64, lib is now normally a symlink to lib64, but 
the only stuff that's supposed to be installed directly to lib is arch-
independent stuff.  FEATURES=multilib-strict causes portage to do some 
checks and die if the wrong thing gets installed to lib.  There are not 
regularly supported testing-only profiles that do away with the symlink, 
but that's exactly what they are, not normally/regularly supported, as 
it's not unusual at all for particularly new packages, but also 
occasionally updates from upstream where they played an unexpected trick, 
to put stuff in lib that doesn't belong there.

Some day, probably after portage (or pkgcore or paludis or another 
successor) gets full multi-arch support, and can thus properly track 32-
bit vs 64-bit in a single instance, Gentoo may in fact switch to a 32-bit 
lib in accordance with the LSB.  However, as time rolls on, that becomes 
less and less of an issue, as more and more stuff, even the proprietary 
aka slaveryware that caused the problem to be so big in the first place, 
either gets dumped for newer stuff, or gets native 64-bit versions.  
Thus, as time goes on, there's gradually less and less reason to even 
have 32-bit on the system at all, even for those who have no ethical/
legal/freedom/practical compunctions about running proprietaryware.

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

-- 
gentoo-amd64@g.o mailing list