Re: [gentoo-user] What is recommended behavior for complete updating of an old system ?

[michael@michaelshiloh.com]

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 <listjiro@gmail.com> 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