[gentoo-amd64] Re: emerge system set list

[Duncan]

Daiajo Tibdixious posted on Tue, 05 Jun 2012 09:52:15 +1000 as excerpted:

> I forgot about the dependent packages. I might forget about separating
> system & world & just backup all the binpkg's

FWIW, that's pretty much what I do here (but with all packages together, 
not separate @system/@world).  I use FEATURES=binpkg and have a separate 
binpkgs partition, then a second partition of the same size that I mkfs 
and copy everything from the first one to, every so often.

Binpkg partition size is now 8 gigs.  3 gigs works if you clean out all 
the old binpkgs regularly (eclean), and I ran 4 gigs for awhile, but I 
run the kde betas (as of yesterday, 4.8.80 aka 4.9-beta1) and like to 
keep plenty of room for the last upstream-stable I had (4.8.3) plus the 
last and current betas, and found 4 gig a bit tight for that, so when I 
upgraded disks, I doubled the size to 8 gigs, tho 6 probably would have 
done as well.

It doesn't matter so much on a packages partition as the files are large, 
but FWIW I run reiserfs with tail-packing on, as I can't see wasting all 
the partial blocks, and reiserfs has been quite stable for me (even thru 
hardware issues) since data=ordered mode was introduced back in 2.6.16 or 
so.  It makes a BIG difference on the sources (both gentoo/overlay trees 
and kernel, plus ccache) partition, tho.  (I'm looking forward to the 
still experimental btrfs, but tried it recently and it's not solid yet, 
particularly in the case of hard-reboots, etc.  Lost files is NOT my 
thing, and missing parts of files or having files replaced with the 
contents of other files is worse, hard reboot or no hard reboot, so it 
was back to the tried and tested, for me.)

FWIW, I use the dup-partition thing for everything.  Put it on raid1 
(again, looking forward to btrfs raid1 mode) if you have it, so losing a 
disk won't kill things either, and you're set for either loss of disk 
(raid1) or fat-fingering something (backup partition).  Three copies of 
root (working and two backups), in case both the working and a backup go 
down while I'm doing maintenance, two of everything else.

(If you have multiple disks in md/raid1 or similar, making /boot a normal 
partition or a raid1 of half the drives if more than two, with its backup 
a similar partition on the other drive(s), works well.  Select which one 
you want to boot in bios, and upgrade one at a time then test before 
upgrading the other, when doing bootloader upgrades.  That works well for 
git kernels too, only upgrading the backup /boot with full kernel 
releases, keeping the git kernels on the working /boot.  If just a single 
disk, than obviously more than one /boot doesn't help that much since the 
initial sector bootloader can only point to one /boot.)

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