[gentoo-amd64] Re: Upgrading from amd64 to ~amd64.

[Duncan <1i5t5.duncan@cox.net>]

Richard Freeman posted
<33411.202.248.61.99.1129607716.squirrel@gw.thefreemanclan.net>, excerpted
below,  on Mon, 17 Oct 2005 23:55:16 -0400:

> On Mon, October 17, 2005 10:50 pm, Toby Fisher wrote:
>> running system?  Is it just a case of changing to an arch of ~amd64 and
>> doing the upgrade?  I'll bet it isn't which is why I'm asking here -
>> I'd like not to have to start from scratch.
>>
>>
> One tip I have is to avoid doing huge upgrades in a single shot, unless
> it is on a testing-only chroot that you don't care about too much.
> 
> I would probably do an emerge -puD world and look at the likely-huge
> list of packages.  I'd probably manually emerge stuff like portage / gcc
> / glibc / toolchain early on.  I'd also pick out stuff like base system
> files, PAM-related stuff, and any stuff related to servers you depend on
> (maybe samba servers for around the house, a webserver, etc).  I'd
> upgrade these individually so that you don't end up with a box that you
> can't login to with no idea what broke it.  Once you have the guts of
> the system upgraded and the system can actually boot correctly then you
> can upgrade the rest and just fix the occassional non-critical breakage
> as you have time.

Someone else mentioned this as well, and I'll third it.

I /always/ do an emerge --pretend --update --deep world run first, so I
have some idea of how big my upgrade is going to be.  (I also use
--verbose, so I get a look at the USE flags and can change anything I
don't like.  This is probably a VERY good idea upgrading to ~arch from
stable, because it's almost certain some of the newer packages will have
changed USE flags vs what you currently have merged.) After each level
below, I run etc-update, so the number of pending updates doesn't get out
of hand. Of course, if the current version of any package later in the
process isn't enough for the new version of something early in the
process, it'll bring in the dependency as necessary, so if that happens,
naturally, do the dependency ordered thing rather than the order proposed
below.

After the emerge , if portage is to be upgraded, that's always the first
thing I upgrade.  The idea is that sometimes that upgrade might be fixing
something subtly broken with an earlier version, or at least the newer
version might be more efficient, so I always upgrade portage first.

Then I upgrade things like gcc and binutils, because newer versions of
those should make the compiled binaries of all the other packages that 
much improved.  Also at this level would be autoconf/automake upgrades.

Next are the general Unix utilities like util-linux, fileutils, file,
grep, sed, gawk, etc, because as the utilities in these are often called
from ebuilds, I want to be working with the latest versions when I emerge
other stuff.

Next would be linux-headers and glibc.

Next are the system boot dependencies, baselayout with its boot scripts,
udev, the kernel if you deal with it from portage (I manage mine
separately, downloading, verifying authenticity, configuring/patching, and
compiling, and installing, directly off of kernel.org, as I learned that
with Mandrake before I ever switched to Gentoo, had my own set of scripts
to deal with it, and saw no need to change what already worked well, when
I switched to Gentoo), etc.

At this point, after running etc-update, it's a good idea to reboot and
ensure the new system layout still works.  That's /always/ a /very/ good
idea every time baselayout is upgraded.  If something's strange with it, I
want to find out about it right away.  

Note especially that baselayout is one of the packages that CAN screw up
the system, and that ~arch means you are getting it after it works for the
maintainer, but before it has been widely tested on all the different
configurations out there, so sometimes something DOES go wrong with ~arch
baselayout, and you end up either booting to emergency mode (thus directly
to shell, without the regular sysinit based boot process, no system
services running, nothing but root mounted, etc -- be sure you know how to
do this if you run ~arch baselayout) or to your rescue partition or disk
(I use a rescue partition that's in effect a known-working and
tested-working snapshot of my working system, others prefer a LiveCD
rescue disk of some sort).

Further, you know the --changelog (-l) switch on emerge?  Baselayout's a
VERY good package to get in the habit of running that on (with --pretend,
of course), to actually see what the changes are, before you merge it, so
if there are issues, you have a good idea where they'll be and what sort
of thing changed that might cause them, before you reboot and find it
doesn't work, and haven't the foggiest!

After the baselayout level and a successful reboot to test it, I run an
emerge --update --deep --pretend --system, and see what else in system
will be upgraded, if anything.  Then I'll usually do that all together,
completing the rest of the system level.

After the system update is complete, I'll start on world, again doing the
-puD thing first, to get a list.

xorg is in world, and I'll almost always update it by itself.

Next would be the likely fairly large group of packages that make up your
preferred X environment.  (Here, it's  KDE.)  Note that stuff like KDE is
slotted, and you can configure to launch either version, old or new.  I'll
usually emerge the new base system (arts, kdelibs, the individual packages
from kdebase that I have to to launch the new version) first, then test
it, before emerging the rest.

Everything else is more or less a matter of personal priority.  Here, I'd
continue by emerging the rest of a "functional" KDE system, so konqueror,
kmail, and the like, before I did all the other "optional" packages, both
KDE and others from the world step listed to upgrade.

Some additional pointers...

** Add FEATURES=buildpkg to your make.conf.  That feature will cause
portage to automatically create binary packages of everything it merges. 
This cann be quite useful for backup purposes, and comes in /very/ handy
on an ~arch system when there's a problem with a newer version.  If you
have the older version still around as a binary package, you don't have to
wait around for it to recompile, to revert to the older known working
version. Of course, having several old versions pre-packaged is also handy
when you haven't used an application in awhile, and want to find out where
the problem was introduced so you can put the info in the bug report you
file, narrowing down the possible issues to the changes between the last
version that works and the first one that doesn't.

FEATURES=buildpkg has saved my *** SEVERAL times.  It's really something
I'd now not want to do without, so I'd certainly recommend trying it. 
Depending on how many old package versions you keep around, expect on
about a gig to two of packages.  I have my packagedir on its own 1-G
partition, which works, but is a bit cramped.  I'll be putting it on a 2-5
gig partition next time I upgrade hard drives or rearrange partitions on
what I have.

** As I said but worth reemphasizing, if you are using ~arch (or even if
using stable, but doubly so using ~arch), ensure you have a working rescue
disk or partition.

** The newest ~arch portage (or is it gentoolkit?) has a couple new tools.
eclean is quite useful, for managing the size of your portage distdir and
packagedir.  It's very easy to run it and have it remove all the "dead"
versions of source files and binpkgs, that don't have ebuilds in portage
any longer, and that's very useful functionality to have!

** Consider using the --oneshot switch with emerge.  Here, I've created an
alias that uses that by default.  This keeps directly emerged packages
from cluttering up your world file, which is handy when you are emerging
by name system dependencies that really don't belong in the world file. 
Since --oneshot is now my default, I don't have to worry about it any more.

** I believe it's already in stable portage, but as it's fairly new, many
Gentoo users probably aren't aware of emerge's --newuse switch.  This
comes in handy for general system maintenance, allowing you to see what
packages were merged with USE flags other than your current set.

** After upgrading to ~arch, run revdep-rebuild (first with the -p option,
of course), to clean up any old dependencies on outdated libraries that 
are no longer around.

** Likewise, you'll probably want to run emerge depclean, to clean out any
unneeded packages.  IT'S **VERY** IMPORTANT TO RUN THIS WITH -p FIRST,
CHECKING THE LIST FOR SANITY BEFORE YOU JUST LET IT REMOVE STUFF YOU KNOW
YOU NEED.  This is especially true if you take my suggestion and make
--oneshot your default.  You can then add any packages it wants to remove
but that you know you need to keep to your world file, before letting it
do its work on the remainder.  Or... simply use the list it creates in
pretend mode, to emerge -C individual packages manually, and never
actually run emerge depclean without --pretend.

After doing a depclean, it's generally wise to run revdep-rebuild once
again, to catch any newly dependency-orphaned packages and remerge them to
link them against newer libraries as necessary.

Together, newuse, depclean, revdep-rebuild, and eclean, make maintaining a
system as cruft free as possible under the more frequent update cycles of
~arch, relatively painless.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list