From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.50) id 1ERpOp-0002ys-GH for garchives@archives.gentoo.org; Tue, 18 Oct 2005 11:12:56 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id j9IB9UXm003437; Tue, 18 Oct 2005 11:09:30 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id j9IB9TE9018967 for ; Tue, 18 Oct 2005 11:09:29 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ERpMT-0002jx-9S for gentoo-amd64@lists.gentoo.org; Tue, 18 Oct 2005 13:10:29 +0200 Received: from ip68-230-97-182.ph.ph.cox.net ([68.230.97.182]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Oct 2005 13:10:29 +0200 Received: from 1i5t5.duncan by ip68-230-97-182.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Oct 2005 13:10:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: Upgrading from amd64 to ~amd64. Date: Tue, 18 Oct 2005 04:09:38 -0700 Organization: Sometimes Message-ID: References: <030001c5d38e$c93d1f10$0203a8c0@oulaptop> <33411.202.248.61.99.1129607716.squirrel@gw.thefreemanclan.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-97-182.ph.ph.cox.net User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Sender: news X-Archives-Salt: d401ae58-1a68-47e5-9ba5-014b2c345a17 X-Archives-Hash: 40a098b228a37b0754c129e0fd88088e 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