Bug 233296 – >=sys-apps/portage-2.2_rc2 does not support interactive ebuilds if in background mode (--jobs or --quiet)

• Status: RESOLVED FIXED
• Product: Portage Development

[Description Jeremy Olexa (darkside) (RETIRED) 2008-07-29 17:00:27 UTC]

If you are in background mode (--jobs) then you cannot accept licenses if needed because it doesn't come to the foreground. This is problematic because it looks like portage has hung when in reality it is just waiting for input.

I spoke with zmedico about this in #gentoo-portage.

[Comment 1 Zac Medico 2008-08-05 22:52:59 UTC]

*** Bug 233977 has been marked as a duplicate of this bug. ***

[Comment 2 Zac Medico 2008-08-05 22:56:47 UTC]

The license acceptance can be handled via ACCEPT_LICENCE and license groups as described in bug #152593. However, support for interactive ebuilds may still be useful for other things such as cdrom_get_cds() in eutils.eclass.

[Comment 3 Jeremy Olexa (darkside) (RETIRED) 2008-08-05 23:03:06 UTC]

(In reply to comment #2)
> The license acceptance can be handled via ACCEPT_LICENCE and license groups as
> described in bug #152593. However, support for interactive ebuilds may still be
> useful for other things such as cdrom_get_cds() in eutils.eclass.

I consider this a pretty good flaw in portage-2.2 only because it appears to the end-user that the job has hung. Can portage at least bail out upon detection and say "Hey, you don't accept this license" with an informative message about how to accept the license? I don't think it is a requirement to move the message to the forground and ask for user-input yet. That can come later, if it is possible.

Thoughts?

[Comment 4 Jeremy Olexa (darkside) (RETIRED) 2008-08-14 15:22:46 UTC]

For future reference please see this thread:
http://thread.gmane.org/gmane.linux.gentoo.devel/57625

[Comment 5 Anders Aagaard 2008-08-14 16:01:15 UTC]

*** Bug 234738 has been marked as a duplicate of this bug. ***

[Comment 6 Zac Medico 2008-09-13 21:39:00 UTC]

*** Bug 237589 has been marked as a duplicate of this bug. ***

[Comment 7 Zac Medico 2008-09-26 18:13:13 UTC]

Yesterday the council approved PROPERTIES=interactive for use in ebuilds. I've deployed support on the master rsync mirror for PROPERTIES in the metadata cache, so we can go ahead and start setting it in ebuilds.

[Comment 8 Zac Medico 2008-10-21 23:33:00 UTC]

Created attachment 169362 [details, diff]
force all output to stdio if the merge list contains at least one interactive package

If this patch is saved as /tmp/interactive.patch, then it can be applied as follows:

  patch /usr/lib/portage/pym/_emerge/__init__.py /tmp/interactive.patch

This patch forces the output to stdio for all packages in the merge list if at least one of the packages is interactive. I intend to improve support in the future, so that stdio is only used for interactive packages.

[Comment 9 Zac Medico 2008-11-02 00:58:08 UTC]

This is fixed in 2.2_rc13.

[Comment 10 Mike Auty (RETIRED) 2008-11-11 20:26:54 UTC]

Just to let you know, I'm now using PROPERTIES="Interactive" in the vmware-workstation-6.5.0 ebuild...

[Comment 11 Pacho Ramos 2009-04-04 12:19:01 UTC]

Maybe would be better try to merge interactive package at first (when possible) and, once it's merged and user has interactued, emerge could merge the remaining packages with desired jobs setting.

For example, I am seeing this problem while running "emerge -avuDN --jobs=10 world", emerge is using --jobs=1 because there is one interactive package

Thanks

(Should I open a new bug report for this?)

[Comment 12 Zac Medico 2009-04-04 18:45:28 UTC]

(In reply to comment #11)
> For example, I am seeing this problem while running "emerge -avuDN --jobs=10
> world", emerge is using --jobs=1 because there is one interactive package
> 
> Thanks
> 
> (Should I open a new bug report for this?)

Yes please file an "enhancement" bug for that.

[Comment 13 Pacho Ramos 2009-04-07 09:11:50 UTC]

http://bugs.gentoo.org/show_bug.cgi?id=265267

Done, thanks :-)