Bug 183683 – On resume, USE flags given on the command line aren't taken into account

• Product: Portage Development
• Status: RESOLVED DUPLICATE

[Description Peter Thomassen 2007-06-29 21:20:25 UTC]

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?).)

Reproducible: Always

Steps to Reproduce:

[Comment 1 Zac Medico 2007-07-01 16:19:47 UTC]

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?

[Comment 2 Peter Thomassen 2007-07-01 18:25:12 UTC]

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.

[Comment 3 Marius Mauch (RETIRED) 2007-10-06 16:00:20 UTC]

@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.

[Comment 4 Marius Mauch (RETIRED) 2007-11-09 16:24:17 UTC]

(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

[Comment 5 Marius Mauch (RETIRED) 2008-03-02 15:13:43 UTC]

*** This bug has been marked as a duplicate of bug 199408 ***