Mailing List Archive: emerge -e question Was: GCC-3.4 will be marked stable in ~1 hour on x86

emerge -e question Was: GCC-3.4 will be marked stable in ~1 hour on x86

Jun 17, 2008, 12:59 AM

Post #1 of 3 (121 views)

Mark Loeser posted <20051202215523.GA25803@aerie.halcy0n.com>, excerpted
below, on Fri, 02 Dec 2005 16:55:23 -0500:

> [1] http://www.gentoo.org/proj/en/base/x86/gcc-upgrading-guide.xml

Reading this reminds me of a question I've had since I tried emerge -eav
world last time:

When portage merges, it stops the emerge process, updates its metadata or
whatever, then restarts the process. With the -e in there, at least here,
it reissued the same command over again, thereby restarting the process
from the beginning and of course, upon getting to portage, looping yet
again!

I don't know how many times it looped before I decided to check on things
and figured out what was happening, at which point I was able to do an
emerge -pe and get a listing, then delete <=portage from the list and just
remerge what came after.

I've yet to see anyone else mention this, and certainly the document above
doesn't mention it as an issue when invoking emerge -e world, so that
reasonably means I experienced the loop when others don't. Why might this
be (I know the reason for portage stopping and recalculating, but why is
it apparently not hitting others), and what can I do to prevent it the
next time I do an emerge -e world?

Maybe it was because I was using -KuD also, to remerge/upgrade from binary
packages? (Hard disk trouble, I was remerging the binary packages to
bring up2date an old installation snapshot.)

--
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-dev@gentoo.org mailing list

Re: emerge -e question Was: GCC-3.4 will be marked stable in ~1 hour on x86 [ In reply to ]

jstubbs at gentoo

Dec 3, 2005, 7:13 PM

Post #2 of 3 (117 views)

Permalink

On Saturday 03 December 2005 21:47, Duncan wrote:
> Mark Loeser posted <20051202215523.GA25803@aerie.halcy0n.com>, excerpted
>
> below, on Fri, 02 Dec 2005 16:55:23 -0500:
> > [1] http://www.gentoo.org/proj/en/base/x86/gcc-upgrading-guide.xml
>
> Reading this reminds me of a question I've had since I tried emerge -eav
> world last time:
>
> When portage merges, it stops the emerge process, updates its metadata or
> whatever, then restarts the process. With the -e in there, at least here,
> it reissued the same command over again, thereby restarting the process
> from the beginning and of course, upon getting to portage, looping yet
> again!

This is incorrect. Portage should only restart if the version that was merged
does not match the internally recorded version. There was one or two releases
that had an incorrect internal version but not for at least a year. However,
if the version has changed and portage does restart itself then any packages
listed before portage will be merged again.

> Maybe it was because I was using -KuD also, to remerge/upgrade from binary
> packages? (Hard disk trouble, I was remerging the binary packages to
> bring up2date an old installation snapshot.)

Perhaps you were using one of the broken versions?

--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list

Re: emerge -e question Was: GCC-3.4 will be marked stable in ~1 hour on x86 [ In reply to ]

1i5t5.duncan at cox

Jun 17, 2008, 12:59 AM

Post #3 of 3 (116 views)

Permalink

Jason Stubbs posted <200512041113.54555.jstubbs@gentoo.org>, excerpted
below, on Sun, 04 Dec 2005 11:13:54 +0900:

>> Reading this reminds me of a question I've had since I tried emerge -eav
>> world last time:
>>
>> When portage merges, it stops the emerge process, updates its metadata or
>> whatever, then restarts the process. With the -e in there, at least here,
>> it reissued the same command over again, thereby restarting the process
>> from the beginning and of course, upon getting to portage, looping yet
>> again!
>
> This is incorrect. Portage should only restart if the version that was merged
> does not match the internally recorded version. There was one or two releases
> that had an incorrect internal version but not for at least a year. However,
> if the version has changed and portage does restart itself then any packages
> listed before portage will be merged again.
>
>> Maybe it was because I was using -KuD also, to remerge/upgrade from binary
>> packages? (Hard disk trouble, I was remerging the binary packages to
>> bring up2date an old installation snapshot.)
>
> Perhaps you were using one of the broken versions?

Most likely so. At the time, the portage database was out of sync with
what was actually merged, because the database was new (on /var, which
wasn't affected) but I was working from an old root and /usr set. Since I
had all the binary packages, I figured the easiest way to get everything
back upto-date and lined up again, was to do an emerge --emptytree
--packageonly, and I was rather frustrated to find it kept looping, when
I'd never seen anything in the documentation saying to watch out for
portage or the easiest way to avoid the loop. =8^\

Honestly, I didn't expect it to be absolutely smooth, because that's not
"functioning within design specifications", and I knew it. It's just that
was the only experience with emerge --emptytree I'd had, and I didn't
expect /that/ problem, because it was just too obvious not to be mentioned
if it was happening to everyone, or whatever.

Anyway, I have an explanation for what had been an unexplained anomaly,
now, and my level of peace with the world just went up accordingly, so
very much thanks!

--
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-dev@gentoo.org mailing list