Summary: | sys-apps/portage: emerge ability to exclude interactive packages | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Pacho Ramos <pacho> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | esigra |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 184128, 210077, 288499 |
Description
Pacho Ramos
![]() While it's nice to merge them as soon as possible, dependencies can interfere with this goal. So, a more general solution is to allow interactive ebuilds to temporarily take exclusive control of the console when necessary. The current behavior of forcing --jobs=1 is only a workaround for lack of the required coordination code. It would be a much better solution of course :-) Maybe a workaround until this is implemented would be to allow us to run: # RESTRICT=interactive emerge -avuDN --jobs world for temporally skipping interactive ebuilds Thanks In 2.2_rc40 we have ACCEPT_PROPERTIES support, so you can do ACCEPT_PROPERTIES="* -interactive" in order to prevent interactive packages from being pulled into the graph. I plan do add a --accept-properties option since using environment variables directly is not very nice (it's prone to leakage and we may eventually disable it by default). The you be able to use --accept-properties="* -interactive" to get the desired behavior. Great :-D Thanks a lot for your work! The --accept-properties option is in svn r14501. With it you can do something like this: emerge -uDN world --accept-properties=-interactive With default configuration, that will change your effective ACCEPT_PROPERTIES setting to "* -interactive". After you've done all of your non-interactive updates, you'll be able to to your interactive ones separately. The code from bug 137562 should ensure that any packages which depend on interactive packages are properly dropped from the updated. The above approach seems pretty practical to me. After the bulk of you updates are done, you can do your interactive updates separately. One problem I see with trying to adjust merge order specifically for interactive packages is that it might not always be optimal, since the interactive packages might have dependencies which prevent them from being promoted to the beginning of he merge list. Because of this, there would be no guarantee that the merge order could be adjusted to your satisfaction. No problem, --accept-properties=-interactive looks really great for me. Thanks :-D Ok, we'll consider this solved by --accept-properties then. It's released in 2.2_rc44. OK but, maybe would be interesting to inform the user about this way to solve portage disabling jobs due interactive packages maybe reflecting this in man page or even suggesting this with the current message that notifies the user that portage will disable jobs because of interactive packages found Thanks (In reply to comment #9) > OK but, maybe would be interesting to inform the user about this way to solve > portage disabling jobs due interactive packages maybe reflecting this in man > page or even suggesting this with the current message that notifies the user > that portage will disable jobs because of interactive packages found Thanks, I've added hints in both places, in svn r14507 and r14508. This is fixed in 2.1.7 and 2.2_rc45. |