Richard Freeman <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 -- [EMAIL PROTECTED] mailing list
