Assume, make.conf says USE="-X".
$ USE="X" emerge -va xine-ui
If the emerge process aborts (by Ctrl+C or by error), one can resume it:
$ emerge --resume
In this case, the manually specified X USE flag is gone. One must use:
$ USE="X" emerge --resume
I think it's up to portage to manage such build process information.
(This may especially become interesting when USE-based dependencies are supported (are they already?).)
Steps to Reproduce:
I don't want to be overly pedantic here but just in case you don't know, generally it's better to use /etc/portage/package.use instead of setting flags through the environment like that.
I'd like --resume to automatically recalculate dependencies from scratch since the system state might have changed since the command was initially given. In that case, it might make more sense to use whatever the current USE settings are (which may include the current value of the USE environment variable). I suppose we could add a --old-use option so that the original USE settings are reused during --resume. But again, isn't it better practice to set the flags in make.conf or package.use in order to make them persistent?
Of course, setting USE flags in make.conf or package.use is better, but anyway portage should show reasonable behavior in the other case, too. (There are reasons for not setting USE flags in config files, p.ex. when experimenting with the impact of different flags on the build time or dependencies etc.)
If the system state has changed between an emerge command and the --resume action, I'd prefer to have the whole action discarded that was to be resumed, because the occurrence of other dependencies may cause actions which the user couldn't have had in mind when issuing the original emerge command. That is, the process cannot be resumed in the way it was begun. Under such circumstances, the user should explicitly approve the new conditions by starting a fresh emerge run.
@Zac: what you describe (recalculating) doesn't really fit into the semantics of a "resume" operation, more a "restart-from-position". Lets not redefine semantics of options, that's just causing trouble later on when nobody knows what a option actually does anymore (see --update).
The behavior you describe should actually be quite easy to implement if you build a package set on top of the resume list.
(In reply to comment #3)
> The behavior you describe should actually be quite easy to implement if you
> build a package set on top of the resume list.
Hmm, not as easy as I thought, as the set would have to recreate the depgraph itself and then remove the already merged packages
*** This bug has been marked as a duplicate of bug 199408 ***