I caught just a hint of some kind of recent trouble when updating on
this list a few days ago but lost track of the thread or message.

I'd like to do update world and am some 4-5 mnths out of date right
now.

Am I likely to hit some horrible snag that has come up recently.

PS - I'm already past the change from hda to sda

On Wed, Sep 14, 2011 at 2:32 PM, Harry Putnam <reader@newsguy.com> wrote:
> I caught just a hint of some kind of recent trouble when updating on
> this list a few days ago but lost track of the thread or message.
>
> I'd like to do update world and am some 4-5 mnths out of date right
> now.
>
> Am I likely to hit some horrible snag that has come up recently.
>
> PS - I'm already past the change from hda to sda

I updated my laptop (using ~amd64) which went ~9 months or so without
being updated, and it was fine... It took a few days of compiling, but
it was fine. The usual things apply, be careful when upgrading config
files, kernel options, rebuild your x11 drivers after upgrading xorg,
rebuild libtool after upgrading gcc, etc. I don't remember any gotchas
though.

I personally like to upgrade gcc first off (and its deps), then run
gcc-config to (re)set the new version, re-emerge libtool,
fix_libtool_files.sh, then I update the system set, etc-update, reboot
to be sure everything is sane, then upgrade world after that.
Depending on how ancient the kernel is, upgrading the kernel might
fall somewhere in the middle of that process (and updating
linux-headers and glibc as appropriate). Usually there are copious
amounts of emerge @preserved-rebuild, revdep-rebuild and emerge
--depclean along the journey, too.

Harry Putnam wrote:

I caught just a hint of some kind of recent trouble when updating on
this list a few days ago but lost track of the thread or message.

I'd like to do update world and am some 4-5 mnths out of date right
now.

Am I likely to hit some horrible snag that has come up recently.

PS - I'm already past the change from hda to sda





I agree with the other post about gcc but you should also update portage
shortly after that. The newer portage is able to handle more issues for
you and may save you some time. So, I would update gcc, portage then
give world a try. If it looks bad, try system first. That could
correct some things.


The only other gotcha I can think of is openrc/baselayout. Do NOT
reboot until you are sure your config files are updated. The only thing
I really had to change myself was my net file. Their script works well.


Anothet thing, I would just do a emerge -e qorld and call it a day. You
will have a few blockers, most openrc stuff, but those can be handled
quickly. Just make sure you don't have a power problem. ;-)


Dale

:-) :-)

On Wed, 14 Sep 2011 17:03:34 -0500, Dale wrote:

> I agree with the other post about gcc but you should also update
> portage shortly after that. The newer portage is able to handle more
> issues for you and may save you some time. So, I would update gcc,
> portage then give world a try. If it looks bad, try system first.
> That could correct some things.

Update portage first, that way you are using the newest version when
updating gcc and glibc.

Personally, I'd trust portage to know better than me and do

emerge -au @system
emerge -auDN @world

--
Neil Bothwick

And God said "Let there be light" and there was light.
There was still nothing, but you could see it better.

On Wed, Sep 14, 2011 at 3:19 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Wed, 14 Sep 2011 17:03:34 -0500, Dale wrote:
>
>> I agree with the other post about gcc but you should also update
>> portage shortly after that. *The newer portage is able to handle more
>> issues for you and may save you some time. *So, I would update gcc,
>> portage then give world a try. *If it looks bad, try system first.
>> That could correct some things.
>
> Update portage first, that way you are using the newest version when
> updating gcc and glibc.
>
> Personally, I'd trust portage to know better than me and do
>
> emerge -au @system
> emerge -auDN @world
>
> --
> Neil Bothwick

Not that I know anything about the OP's environment but on my KDE
desktop I've recently (last 6 months or so) found that

emerge -fDuN @system

won't work as it ends up with unresolvable conflicts. May just be the
way I've set up my flags.

I completely agree with the sentiment:

1) Update the system's view of portage
eix-sync

2) emerge portage

3) Do the rest of the work

emerge -fDuN @world
emerge -pvDuN @world

Fix USE flag issues, if any

4) Do the build

emerge -DuN -j13 @world

Cheers,
Mark

On Wed, 14 Sep 2011 15:37:15 -0700, Mark Knecht wrote:

> 3) Do the rest of the work
>
> emerge -fDuN @world
> emerge -pvDuN @world
>
> Fix USE flag issues, if any
>
> 4) Do the build
>
> emerge -DuN -j13 @world

There's not point in doing the fetch first, portage has done parallel
fetching for some time - it's faster to let the distfiles download while
the first package is compiling.

emerge -auDN @world covers all of that - except the -j which is
system-dependent.


--
Neil Bothwick

The modem is the message.

Mark Knecht wrote:

On Wed, Sep 14, 2011 at 3:19 PM, Neil Bothwick<neil@digimed.co.uk> wrote:

On Wed, 14 Sep 2011 17:03:34 -0500, Dale wrote:


I agree with the other post about gcc but you should also update
portage shortly after that. The newer portage is able to handle more
issues for you and may save you some time. So, I would update gcc,
portage then give world a try. If it looks bad, try system first.
That could correct some things.

Update portage first, that way you are using the newest version when
updating gcc and glibc.

Personally, I'd trust portage to know better than me and do

emerge -au @system
emerge -auDN @world

--
Neil Bothwick

Not that I know anything about the OP's environment but on my KDE
desktop I've recently (last 6 months or so) found that

emerge -fDuN @system

won't work as it ends up with unresolvable conflicts. May just be the
way I've set up my flags.

I completely agree with the sentiment:

1) Update the system's view of portage
eix-sync

2) emerge portage

3) Do the rest of the work

emerge -fDuN @world
emerge -pvDuN @world

Fix USE flag issues, if any

4) Do the build

emerge -DuN -j13 @world

Cheers,
Mark




A lot of this is going to depend on *what* needs to be updated. I did
want to mention openrc because that requires user input for sure. Me, I
would sync and look at the output of emerge -uvDNa world and just see
how much there is to chew on. If the list is really really long, I
would do a emerge -e world after upgrading gcc and portage. When that
is done, the OP should have a really sane system since everything will
be newly compiled.


Again, that is just me. Over the years I have learned how to avoid some
update issues. The most important thing to watch for tho is openrc.
Miss that and rebooting may only be a dream.


YMMV.

Dale

:-) :-)

On Wed, Sep 14, 2011 at 4:46 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Wed, 14 Sep 2011 15:37:15 -0700, Mark Knecht wrote:
>
>> 3) Do the rest of the work
>>
>> emerge -fDuN @world
>> emerge -pvDuN @world
>>
>> Fix USE flag issues, if any
>>
>> 4) Do the build
>>
>> emerge -DuN -j13 @world
>
> There's not point in doing the fetch first, portage has done parallel
> fetching for some time - it's faster to let the distfiles download while
> the first package is compiling.
>
> emerge -auDN @world covers all of that - except the -j which is
> system-dependent.
>
>
> --
> Neil Bothwick

Quite true about the parallel fetch, but I still do this anyway
because I want to know all the code is local before I start. With 12
processor cores I often build the first file before the second has
been downloaded. Also I don't want to start a big build, say 50-70
updates, and then find out an hour later when I come back that some
portage mirror choked on finding a specific file and the whole thing
died 10 minutes in. This way I have a better chance of getting to the
end in one pass.

Anyway, it works well for this old dog, and in my mind there is a good
reason to fetch before building but I can see how others might not
want to do that.

- Mark

Mark Knecht wrote:

On Wed, Sep 14, 2011 at 4:46 PM, Neil Bothwick<neil@digimed.co.uk> wrote:

On Wed, 14 Sep 2011 15:37:15 -0700, Mark Knecht wrote:


3) Do the rest of the work

emerge -fDuN @world
emerge -pvDuN @world

Fix USE flag issues, if any

4) Do the build

emerge -DuN -j13 @world

There's not point in doing the fetch first, portage has done parallel
fetching for some time - it's faster to let the distfiles download while
the first package is compiling.

emerge -auDN @world covers all of that - except the -j which is
system-dependent.


--
Neil Bothwick

Quite true about the parallel fetch, but I still do this anyway
because I want to know all the code is local before I start. With 12
processor cores I often build the first file before the second has
been downloaded. Also I don't want to start a big build, say 50-70
updates, and then find out an hour later when I come back that some
portage mirror choked on finding a specific file and the whole thing
died 10 minutes in. This way I have a better chance of getting to the
end in one pass.

Anyway, it works well for this old dog, and in my mind there is a good
reason to fetch before building but I can see how others might not
want to do that.

- Mark




tail -f /var/log/emerge-fetch.log

That way you can be compiling and watching the fetching process at the
same time. If something fails, it'll be printer there. I use it all
the time here. I only have 4 cores here tho. :-P


Dale

:-) :-)

On Wed, Sep 14, 2011 at 5:16 PM, Dale <rdalek1967@gmail.com> wrote:
> Mark Knecht wrote:
>>
>> On Wed, Sep 14, 2011 at 4:46 PM, Neil Bothwick<neil@digimed.co.uk> *wrote:
>>>
>>> On Wed, 14 Sep 2011 15:37:15 -0700, Mark Knecht wrote:
>>>
>>>> 3) Do the rest of the work
>>>>
>>>> emerge -fDuN @world
>>>> emerge -pvDuN @world
>>>>
>>>> Fix USE flag issues, if any
>>>>
>>>> 4) Do the build
>>>>
>>>> emerge -DuN -j13 @world
>>>
>>> There's not point in doing the fetch first, portage has done parallel
>>> fetching for some time - it's faster to let the distfiles download while
>>> the first package is compiling.
>>>
>>> emerge -auDN @world covers all of that - except the -j which is
>>> system-dependent.
>>>
>>>
>>> --
>>> Neil Bothwick
>>
>> Quite true about the parallel fetch, but I still do this anyway
>> because I want to know all the code is local before I start. With 12
>> processor cores I often build the first file before the second has
>> been downloaded. Also I don't want to start a big build, say 50-70
>> updates, and then find out an hour later when I come back that some
>> portage mirror choked on finding a specific file and the whole thing
>> died 10 minutes in. This way I have a better chance of getting to the
>> end in one pass.
>>
>> Anyway, it works well for this old dog, and in my mind there is a good
>> reason to fetch before building but I can see how others might not
>> want to do that.
>>
>> - Mark
>>
>>
>
> tail -f /var/log/emerge-fetch.log
>
> That way you can be compiling and watching the fetching process at the same
> time. *If something fails, it'll be printer there. *I use it all the time
> here. *I only have 4 cores here tho. *:-P
>
> Dale

Nahh, you miss my point. I don't want my attention to be anywhere near
the machine except for the 1 minute it takes to run the fetch, and
then assuming that worked, for the 1 minute it takes to start the
build. I then come back an hour or two later, make sure everything got
done and I spent no time of my own fixated on a Gentoo box. Most of
these machines get updated during the day when family is away, but I'm
busy working here at home and don't want to pay much attention just to
get updates done.

I know others are way more involved with every little thing happening
on their machines but I'm not. I run stable with a few ~amd64
packages. I just want to box to get updated and work without a lot of
my time involved. I've done my wife's machine, my father's machine and
my mother's machine this way for years and it doesn't take much
effort. (It just works... (@tm)

On my own 3 Gentoo machines I am a little more involved, but typically
I'm working on them while updating so that's not such a bog deal. My
attention is there.

That said, maybe someone who hasn't touched the machine for 5 months
shouldn't try to do a (mostly) unattended update... ;-)

- Mark