[gentoo-amd64] Re: Change Install Prefix

[Duncan]

Branko Badrljica <brankob@××××××××××.com> posted
49FA4127.5060704@××××××××××.com, excerpted below, on  Fri, 01 May 2009
02:24:07 +0200:

> Question that comes to my mind is why isn't this implemented in portage
> as it is as it's very useful tool.
>
> With it, one could take a disk from machine with hopelessly broken
> system, connect it to good machine and reemerge broken packages, for
> example. Or, say, emerge packages on fast machine and install them to
> slow machine etc etc.

Because, while there are certainly uses for the feature you described, 
there's really no need for it to do either of the above.  Setting $ROOT 
before an emerge works just fine for the broken system case, and I've in 
fact used it for just that tho the details were slightly different than 
your scenario.[1]

I'll be doing a variant of the emerge on a fast machine and install on a 
slow machine in a few months, when I finish a different project I'm 
working on, thus making room for an additional installation image on my 
main machine.  The caveat in my case is that the main machine is a dual 
dual-core Opteron 290 running Gentoo/amd64, while I'll be creating a 32-
bit Gentoo/x86 chroot image for my 32-bit x86 Atom based Acer Aspire One 
netbook.  Thus, I won't be able to use the same packages and will have to 
create an entirely separate set, starting from a stage tarball in the x86 
image just as if I were installing it natively to the amd64 machine, then 
doing an initial full image copy to the AA1, after which I'll emerge to 
the x86 image on the amd64, and emerge --pkgonly on the AA1/netbook.

For that setting ROOT doesn't work quite as well, but after initial image 
installation, the slow machine can simply do an emerge --pkgonly with 
PKGDIR pointed at the appropriate x86 packages dir on the amd64 machine 
(if networked, on the thumbdrive I copied it to, otherwise).

Thus in neither case is it necessary to be able to actually change the 
path they merge to, at least not relative to an already configurable 
ROOT, which provides sufficient flexibility for the above without the 
additional code necessary to manage what you are suggesting.

Also note that since binpkgs are simply tarballs with some extra metadata 
(the ebuild and some other portage data, CHOST, etc) attached to the end 
using xpak, it's possible to use standard archiving tools to unpack 
either individual files or the entire package where desired.  Of course, 
that's scriptable enough.

.....

[1] In my case, I keep two identically sized root partitions, labeled 
root and rootbak.  Root contains all the paths portage installs to as 
well as the installed package database.[2]  Periodically, when the system 
seems in reasonably stable operating condition and I've tested booting, 
portage, gcc, X, and KDE, at minimum, I'll clean-mkfs rootbak, mount 
--bind / somewhere else so I can easily copy everything on just that 
partition, mount rootbak, and do an archive-copy snapshot the working 
system just as it is to rootbak.  That way, if anything ever goes wrong 
on my working LABEL=root, I can simply reboot to LABEL=rootbak and have a 
system in exactly the same working condition as it was when I took the 
snapshot.  In the recovery situation alluded to a brand new ~arch bash 
version simply wasn't working on my normal root, so I couldn't boot to 
it.  I simply booted to rootbak, and then used the rootbak's portage with 
ROOT= set to the mounted LABEL=root, to remerge --packageonly the last 
working bash binpkg to my the LABEL=root mount.  While it's still the 
same machine, it's exactly the same procedure one would use to recover a 
broken machine by connecting its hard drive and mounting its root 
filesystem on a working machine, as you suggested.


[2] I learned the keep-everything-portage-does in sync lesson the hard 
way, awhile back when I had a disk partially go bad and I ended up with 
the partitions for / (including /etc, /bin, /sbin, and /lib(64)), /usr 
(including its lib and (s)bin dirs as well as /usr/share), and /var 
(including the installed package database in /var/db/portage) being three 
different ages, so while I still had a system functional enough to get 
back in shape, portage had no idea what was actually installed and while 
I could remerge binpkgs to catchup, when it tried to cleanup the old 
versions it was trying to cleanup files that weren't there and leaving 
files that were.  That left me having to go thru at least the bin and lib 
dirs with a for loop, doing an equery b for each binary, then removing 
the unclaimed ones.  WHAT A MESS!!  As I said, I learned my lesson, so 
now it's arranged so anything portage installs is on the same partition/
volume as the database saying what's installed, so it all stays in sync.



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