| 1 |
Jason Stubbs posted <200512041113.54555.jstubbs@g.o>, excerpted |
| 2 |
below, on Sun, 04 Dec 2005 11:13:54 +0900: |
| 3 |
|
| 4 |
>> Reading this reminds me of a question I've had since I tried emerge -eav |
| 5 |
>> world last time: |
| 6 |
>> |
| 7 |
>> When portage merges, it stops the emerge process, updates its metadata or |
| 8 |
>> whatever, then restarts the process. With the -e in there, at least here, |
| 9 |
>> it reissued the same command over again, thereby restarting the process |
| 10 |
>> from the beginning and of course, upon getting to portage, looping yet |
| 11 |
>> again! |
| 12 |
> |
| 13 |
> This is incorrect. Portage should only restart if the version that was merged |
| 14 |
> does not match the internally recorded version. There was one or two releases |
| 15 |
> that had an incorrect internal version but not for at least a year. However, |
| 16 |
> if the version has changed and portage does restart itself then any packages |
| 17 |
> listed before portage will be merged again. |
| 18 |
> |
| 19 |
>> Maybe it was because I was using -KuD also, to remerge/upgrade from binary |
| 20 |
>> packages? (Hard disk trouble, I was remerging the binary packages to |
| 21 |
>> bring up2date an old installation snapshot.) |
| 22 |
> |
| 23 |
> Perhaps you were using one of the broken versions? |
| 24 |
|
| 25 |
Most likely so. At the time, the portage database was out of sync with |
| 26 |
what was actually merged, because the database was new (on /var, which |
| 27 |
wasn't affected) but I was working from an old root and /usr set. Since I |
| 28 |
had all the binary packages, I figured the easiest way to get everything |
| 29 |
back upto-date and lined up again, was to do an emerge --emptytree |
| 30 |
--packageonly, and I was rather frustrated to find it kept looping, when |
| 31 |
I'd never seen anything in the documentation saying to watch out for |
| 32 |
portage or the easiest way to avoid the loop. =8^\ |
| 33 |
|
| 34 |
Honestly, I didn't expect it to be absolutely smooth, because that's not |
| 35 |
"functioning within design specifications", and I knew it. It's just that |
| 36 |
was the only experience with emerge --emptytree I'd had, and I didn't |
| 37 |
expect /that/ problem, because it was just too obvious not to be mentioned |
| 38 |
if it was happening to everyone, or whatever. |
| 39 |
|
| 40 |
Anyway, I have an explanation for what had been an unexplained anomaly, |
| 41 |
now, and my level of peace with the world just went up accordingly, so |
| 42 |
very much thanks! |
| 43 |
|
| 44 |
-- |
| 45 |
Duncan - List replies preferred. No HTML msgs. |
| 46 |
"Every nonfree program has a lord, a master -- |
| 47 |
and if you use the program, he is your master." Richard Stallman in |
| 48 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
| 49 |
|
| 50 |
|
| 51 |
-- |
| 52 |
gentoo-dev@g.o mailing list |
Archives