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

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

[Jimmy Rosen]

Hi folks

I recently went through the (minor hell) of updating my old workhorse 
gentoo box. I hadn't touched the system much (apart from open 
services like ssh) for about 1.5 years due to a series of facts:
1) It just worked so darned nice.
2) My phd endstretch didn't leave much time to computer fiddling, and 
the cluster just worked so darned nice (diskless SSI booting from the 
original gentoo machine (see above)).
3) It lived behind a nice firewall which I trust enough (yes I'm a bit 
naive) and the open services such as ssh had been updated more 
regularly.

Now I had a bit of time and sice I had moved to France for my post doc 
I had to get skype in/out working, which didn't want to install 
nicely. So I thought a thorough general system update was overdue.

First, my questions, then (if you really want) the arduous story on 
how I did it. Feel free to comment, give tips and point out my 
mistakes.

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
I have an unexplainable fobia against --depclean though. 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.

Secondary:
How often should one update the system to minimize hassles with broken 
packages?
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.



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
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).

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?

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)

What somethingsomething-update programs should I run during the 
process?
python-updater
perl-clenaner
java-config
opengl-update
modules-update
--- what am I missing -- ?

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)?



In retrospect it might have been faster to simply do a reinstall or 
--emptytree. Sorry for issuing such a blasphemous statement on this 
list.


Thankful for input on the matter.

Jimmy
-- 
gentoo-user@gentoo.org mailing list

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

[Bob Sanders]

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

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

[abhay]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

On Saturday 12 Nov 2005 8:52 am, Bob Sanders wrote:
> 	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
Even though I am not facing problems like the original thread starter but I 
have always thought that what would I do a year down the lane when stuff like 
gcc/glibc (and other important things) are upgraded in major ways. These 
commands will help :-)

Thanks from my side.

Abhay

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[michael]

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

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

[Jimmy Rosen]

Hi

Assembling a guide of recommended update usage seems like a good idea.
Unfortunately I don't have much time (or much knowledge) on the 
matter, and submitting the cluster setup as docs and ebuild has 
higher priority (which doesn't mean I have much time for that 
either).

Do you know if there is a working pipline for "newbie started" docs or 
ebuilds, where more experienced people can make a sanity check and 
much needed corrections before it gets submitted to the rest of the 
world (including other clueless newbies who would not recognize the 
author's madness)?


Jimmy


BTW thanks for the info Bob, helps a lot. I got the use flags in 
order, and after the last --newuse update even revdep-rebuild stopped 
complaining.


On Monday 14 November 2005 05.36, michael@michaelshiloh.com wrote:
> 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