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 1EbYCU-00052R-GJ for garchives@archives.gentoo.org; Mon, 14 Nov 2005 06:52:23 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jAE6pK9c028701; Mon, 14 Nov 2005 06:51:20 GMT Received: from mail.magrittesystems.com (adsl-64-173-154-114.dsl.snfc21.pacbell.net [64.173.154.114]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jAE6kPvp012134 for ; Mon, 14 Nov 2005 06:46:26 GMT Received: by mail.magrittesystems.com (Postfix, from userid 1000) id 7D9023C13B6; Sun, 13 Nov 2005 20:36:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.magrittesystems.com (Postfix) with ESMTP id 478603C0073 for ; Sun, 13 Nov 2005 20:36:45 -0800 (PST) Date: Sun, 13 Nov 2005 20:36:44 -0800 (PST) From: michael@michaelshiloh.com X-X-Sender: michael@mail.magrittesystems.com To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] What is recommended behavior for complete updating of an old system ? In-Reply-To: <20051111192206.5cb19577@chi.speakeasy.net> Message-ID: References: <200511111646.41923.listjiro@gmail.com> <20051111192206.5cb19577@chi.speakeasy.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Archives-Salt: f59a3871-85a8-4626-be68-75f7e954cb0f X-Archives-Hash: 1eccce07ebf151f560282eb58d8976ad If ever there was a frequently asked question, it's this, or the general family of "what's the best way to do an update in this situation?", like: >> What is a recommended way to update an old system to minimize >> the amount of broken ebuilds? > What's the best way to do an update of an old machine that > takes a long time to compile, or an embedded system? What's the best way to keep a machine completely up-to-date with the very latest, stability be damned?? What's the best way to keep a machine reasonably up-to-date, while keeping the machine stable and running? I couldn't find any of these in a FAQ on the gentoo website. Perhaps it's there and I missed it. But if indeed this FAQ lacks an answer, can we compose one from this discussion? Michael On Fri, 11 Nov 2005, Bob Sanders wrote: > On Fri, 11 Nov 2005 16:46:41 +0100 > Jimmy Rosen wrote: > > >> Primary: >> What is a recommended way to update an old system to minimize the >> amount of broken ebuilds? >> Is emerge --emptytree world a good idea? Is it better than a clean >> install? Or is the documentation's way good enough even for a very old >> system: >> emerge --update --deep --newuse world >> emerge --depclean >> revdep-rebuild > > For an old machine that takes a long time to compile, or an embedded system - > > emerge sync once per week and let it run over the weekend doing updates. > > About once per year - > - emerge sync > - ufed and check out the USE flags. Some changes occur and they need a > bit of cleaning. > - emerge -eav system (no need to d world.) > - emerge -uDNav world > - python-updater > - perl-cleaner all > - revdep-rebuild > >> I have an unexplainable fobia against --depclean though. > > Then don't. All you care about is the programs you currently use, those others > just sit there taking some space. If you're not obsessive about a little disk space, why > wipe them off the disk? > >> And updating >> everything at once seems a bit reckless, I mean with the age of the >> system it would update almost everything. The package list was a mile >> long, and you never know what will break. >> > > That's why you should keep on a regular update schedule. A lot of programs get > fixed, USE flags change, dependencies change, configuration options get updated. > >> Secondary: >> How often should one update the system to minimize hassles with broken >> packages? > > Me? I do most of my working systems daily - takes about 10 minutes for all 4 systems. > Home systems - daily or weekly. Laptop monthly. Better to see a small problem show > up than wait for it to be buried in a lot of updates and then have to find out which of > 10 or 20 packages caused the issue. > >> Too often, and the hassle of constant upgrading can get tedious even >> if it works ok, and too late, and some odd dysfunctional version >> combinations start showing up that the packages were not really >> tested for, leading to broken ebuilds. >> > > Have you run other distributions where you get the massive binary updates 3 times per year? > Have you had to fun of doing minor package updates in between the massive updates and > then find that the massive update leaves your system completely borked because of conflicts > with the minor updates? And I mean you don't see these until the system tries to reboot, and > then it sometimes won't do that. > >> >> >> I did like this: >> I didn't want to run a clean install or an --emptytree thingie. I >> wanted to take it a few steps at a time, so that if something broke I >> might have an idea about what new packages it was that broke it. >> >> 1) take a backup of the system. I have some modifications >> in /etc/init.d scripts and some extra non-gentoo stuff for clustering >> installed that I didn't want to risk, and I was pretty sure something >> would bork and leave me clueless. lol >> >> 2) emerge sync. Nice, worked. >> emerge *only the most important stuff* (oh, I'm really chicken btw): >> portage, baselayout, etc. >> That brought in some dependencies, but it worked out all right after a >> while and a lot of figuring out the /etc/init.d and config file >> changes that has happened for the last 1.5 years. And some other >> changes as to where certain configs go, and how, and so on. But most >> was easily searchable in docs or forums.gentoo or on this list. >> Reboot here to see if it even booted any more... YEEAAAH! >> >> 3) emerge basic user packages like gcc, glibc, xorg (yes I was still >> on xfree) kernel, etc. >> note: I have to stay on 2.4 because I use openmosix for the >> clustering, and I don't yet trust 2.6om. >> For this I started using --update --deep since I did want an updated >> system, but not all at once. >> This still worked out all right, with just some minor headaches of >> broken ebuilds. And some config files again. >> hrmmpf kernel change means reboot. darned. >> >> 4) emerge --update --deep desktop stuff like KDE, openoffice, >> browsers, etc... >> This started generating Looooooooots of broken packages. I have spent >> many hours looking through the _VERY_NICE_ bugs.gentoo.org. I still >> get bitten by bugs that are filed fixed in mid 2003. lol > > So here's something to chew on - you are running a cluster with a boat load > of desktop apps. And desktop apps have tons of libs that are needed. Plus > the desktop and their apps change a lot - there is a lot of churn in desktop apps. > They are going to break more often. Waiting will just make the breakage worse > and cause all the compiles to occur at one time, instead of being spread out. > >> Some more config file updates, and restarting all significant services >> to use the new software. >> >> 5) Now, muahaha, emerge --update --deep world. Aiaiai. Another batch >> of broken packages, but not the critical ones, since most everything >> necessary has already been updated. >> Some more config files. I _really_ like dispatch-config and cfg-update >> by now. >> >> 6) Well, I'm here now. The system works just fine. And yes, I recently >> remembered that I had forgotten to update the USE flags to cover the >> current situation (stooopid teflon memory). But I hope I can wait >> until the current few remaining problems are out of the way, and then >> I can perhaps (hope and pray) use the eminent and functional(?) >> --newuse (and I do so very much hope works with/as --deep). >> > > You should use them together - emerge -uDNav world > >> I still have some problems, mainly with skype, which works but have >> some odd dependency thingie with dbus that emerge doesn't like. And >> revdep-rebuild tries to bring in some stuff that are no longer in >> portage. Interesting, though, is that >> equery depends '=pack-group/packagename-x.y.z' >> doesn't report anything depending on those old packages any more after >> all the updates. How can I figure out what wants them? >> > > Try the packages with emerge -uDNav package package etc... > >> revdep-rebuild? is it safe to use, and safe with --package-names >> (since just about every single package it's trying to bring in is no >> longer in the portage tree) >> > > All it's doing is creating an - emerge, command. If you run - revdep-rebuild -p, > then at the end of the pretend mode, do a - rm -rf /root/.revdep-rebuild.*, > you can take the emerge line and do as many or as few as you want. > >> What somethingsomething-update programs should I run during the >> process? >> python-updater >> perl-clenaner >> java-config >> opengl-update >> modules-update >> --- what am I missing -- ? >> > > Nothing really if you do the --newuse, as well. > >> Is udev supported on 2.4.26+? would it be useful instead of devfs? and >> is there a *really* good guide for switching (that might warn me of >> the common problems I'm bound to run into)? >> >> > > No. Udev is 2.6 only. And a good guide is - > http://www.gentoo.org/doc/en/udev-guide.xml > >> >> In retrospect it might have been faster to simply do a reinstall or >> --emptytree. Sorry for issuing such a blasphemous statement on this >> list. >> > > No, you just need to do the system - emerge -e system > The rest will take care of itself through a emerge -uDNav world. > > Have fun! > > Bob > - > -- > gentoo-user@gentoo.org mailing list > > -- gentoo-user@gentoo.org mailing list