[gentoo-amd64] Re: amd64 -> ~amd64

[Duncan]

"S. M. Ibrahim (Lavlu)" <smibrahim@×××××.com> posted
4997275b0609210926m2bca5b30uec5869f00d521091@××××××××××.com, excerpted
below, on  Thu, 21 Sep 2006 22:26:30 +0600:

> what is the easy way to upgrade to ~amd64 from amd64 ??

Pretty much just set the new keyword in make.conf...

ACCEPT_KEYWORDS="~amd64"

... and do the normal emerge --update --deep --newuse world.

Of course, the usual caveats apply.  Do --pretend or --ask so you can see
what emerge will do before actually sending it off to do it, and as you'll
likely have a lot of packages to upgrade in a case like this, you may want
to break it into parts.  In particular, you may want to do the system
upgrade first, then world (with update, world won't cause duplication of
the effort you just did with system, unless you also add --emptytree,
which isn't necessary in this case).

You may wish to break it down further than that, even, doing an emerge
--pretend to get the list, then emerge --oneshot <smaller subset list>. 
This not only allows you to do only a few at a time, but also allows you
to run etc-update on a rather smaller set of config files at a time.  I
like doing it this way as it's easier to manage updates of just a few
config files at a time.

In particular, I've found it very helpful to do certain updates all by
themselves.  You normally want to update portage first thing, so all the
other updates use the updated portage, and glibc and gcc when they need
updated top of the list and by themselves as well, straightening out any
config file changes before merging anything else.  It's also helpful to do
baselayout and udev upgrades all by themselves, doing the etc-update then
testing the update by rebooting, if there were many changes.  That way, if
there's a problem, you know right away where to look to fix it, or what
you might want to downgrade if it's /really/ screwed up, before you get
such a huge list of changes it's hard to figure out which one caused the
problem.

Of course, it should go without saying, but it's good advice in any case
and particularly so when running ~arch, make sure you have a tested
alternate boot method, in case something critical like bash or glibc
breaks.  In the two and a half years I've been running Gentoo ~arch, bash
broke once and glibc broke once, leaving the system unbootable until
they were fixed or the upgrade rolled back.  The breaks were quickly fixed
and the bad packages pulled, but if you happened to upgrade in the
few-hour window when the broken package was out, having something else to
boot to to recover certainly saved the day.  Here, I simply keep a backup
/ partition (including /etc, /usr, /var, basically everything emerge
touches, but not /home, /var/log, ...) that I periodically erase and
update, only when I know my main system including a full boot, portage,
gcc, X and KDE, are all working.  That way, if something breaks on the
main system, I can simply boot the backup and go back to work with
everything working, just as it was when I made the backup image.  There's
no hurry to get the broken system fixed and no interruption in normal work
flow, since I have a full working system as the backup.

If you aren't already using it, you may also want to consider
FEATURES=buildpkg in make.conf.  This creates binary packages of
everything you emerge (normally stored in the packages dir of your portage
tree but that's configurable, figure 2-4 gigs space, depending on how often
you run eclean-pkg), making it easy to revert to an old version if
something breaks, without having to recompile it to do so.  This makes
recovering from a gcc or portage borkage in particular, far easier than it
would otherwise 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

-- 
gentoo-amd64@g.o mailing list