Summary: | Emerge --emptytree restarts from beginning while it shouldn't (stage2 install) | ||
---|---|---|---|
Product: | Portage Development | Reporter: | fvincken |
Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
fvincken
2005-07-21 19:49:13 UTC
for a temporary fix I assume that after portage compiles you should be able to cancel the emerge then use --resume and or --skipfirst a few times to get past the loop. Followup: I restarted the install but did "emerge portage" before the "emerge --emptytree system" and the problem didn't occur anymore. Did portage loop more than once? Portage is designed to restart if it upgrades itself, and this may happen once during an emerge -e system. However, if Portage never changes version then it is never restarted. (In reply to comment #3) > Did portage loop more than once? > > Portage is designed to restart if it upgrades itself, and this may happen once > during an emerge -e system. However, if Portage never changes version then it > is never restarted. Indeed it should not loop indefinitely because portage would be upgraded the second time round, I was wrong making that statement. I can't confirm it though since I killed the compilation when it restarted. Since nobody else seems to have this problem I assume it was something weird I did the first time round, and not that the solution was emerging portage *before* the emerge -e system the second time to circumvent the supposed bug. Resolving then, I checked out the code that manages this and it appears to be saneas long as portage.VERSION is set properly. |