When doing an emerge -e world, you usually have to restart compilation a few times due to compile errors (eg. emerge --resume --skipfirst). If you have a typo in this command you can easily loose the ability to resume (eg. I happened to enter emerge resume, without -- and "lost" a day of compilation), because it is assumed to be a new emerge. I wanted to suggest testing for resumable emerges before starting a new one and for example not allow it (except with --force or the like). [Please forgive me if this was discussed/reported before, it's hard to search for "emerge resume" on Gentoo pages :-] Reproducible: Always Steps to Reproduce: 1. 2. 3.
It would be nice if single-package emerges did not mess with the resumable queue... Say you emerge -e world, and it gets to the coreutils before it had the libtermcap dependancy added. If you build this single package, you've lost your resume history, and start over. Is there a simple way (as in plaintext file) to see what is in the queue, and manually insert or delete packages? Even when I want to rebuild the whole world, I tend to want to skip over rebuilding openoffice for example. Something like this would make it possible to interrupt a build, copy the resume queue, build other stuff, copy the resume queue back, and pick up where you left off. That'd be great for making sure everything gets rebuilt using new compiler flags and such, but without worry that you might have to start it all over again.
I would posit a guess ( not being a dev myself ) that this won't get changed. It's hard to make "small merges" not affect the resume queue. However in future versions of portage --resume will be a more robust feature; also with emerge -e world if one piece of the merge depgraph fails the rest will continue to be merged, I wouldn't expect any changes in stable for this, perhaps a warning message saying there is a --resume available, although for most I would think the message would be annoying as hell.
Or I can eat my words ;) Jason is looking into it for you :)
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
This is fixed by now AFAIK.
This is fixed in >=portage-2.1. See bug #156536.
