Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 24513 - Making emerge --resume typo safe
Summary: Making emerge --resume typo safe
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Interface (emerge) (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Portage team
Depends on:
Reported: 2003-07-15 03:13 UTC by Peter Stieglecker
Modified: 2007-01-11 19:06 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Peter Stieglecker 2003-07-15 03:13:10 UTC
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:
Comment 1 Scott Taylor (RETIRED) gentoo-dev 2003-12-31 11:26:44 UTC
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.
Comment 2 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2005-05-10 15:52:40 UTC
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.
Comment 3 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2005-05-10 16:16:49 UTC
Or I can eat my words ;) Jason is looking into it for you :)
Comment 4 Jason Stubbs (RETIRED) gentoo-dev 2005-07-28 07:24:49 UTC
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. ;) 
Comment 5 Marius Mauch (RETIRED) gentoo-dev 2007-01-11 12:16:00 UTC
This is fixed by now AFAIK.
Comment 6 Zac Medico gentoo-dev 2007-01-11 19:06:14 UTC
This is fixed in >=portage-2.1.  See bug #156536.