public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] [RFC] New PROPERTIES=interactive value to identify interactive packages?
@ 2008-08-06  9:22 Zac Medico
  2008-08-06  9:35 ` Alec Warner
  2008-08-07  4:27 ` Jeremy Olexa
  0 siblings, 2 replies; 7+ messages in thread
From: Zac Medico @ 2008-08-06  9:22 UTC (permalink / raw
  To: gentoo-dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello again,

Please consider a new PROPERTIES=interactive setting that allows an
ebuild to indicate that it uses stdin and stdout for user
interaction sometime during the pkg_setup and/or src_unpack phases
(similar to GLEP 52 [1]). This will be another use for the new
PROPERTIES metadata variable that's been proposed for the
implementation of live-sources [2] and virtual [3] PROPERTIES values.

This is useful in cases when it might not be possible for the user
to perform interaction with ebuilds, so they might decide to mask
any ebuilds that exhibit this property. It can also be used to know
in advance whether or not it's safe to run the pkg_setup and
src_unpack ebuild phases in the background. This provides a solution
for bug #233296 [4] by allowing exclusive access to stdin and stdout
to be guaranteed during pkg_setup and src_unpack phases.  We might
also consider adding finer grained values of PROPERTIES such as
interactive-setup, interactive-unpack, and interactive-preinst.

Your comments will be appreciated.

Thanks,
Zac

[1] http://www.gentoo.org/proj/en/glep/glep-0052.html
[2]
http://archives.gentoo.org/gentoo-dev/msg_187585c5d49b69034183719ff473710d.xml
[3] http://article.gmane.org/gmane.linux.gentoo.devel/57610
[4] http://bugs.gentoo.org/show_bug.cgi?id=233296
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiZbWwACgkQ/ejvha5XGaNOxwCdHdmNrDNQdH3PHtciQKINZHRv
6goAnjPL1i3Qwj3cs3lcC+v027TtRFPQ
=RZBV
-----END PGP SIGNATURE-----



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [gentoo-dev] [RFC] New PROPERTIES=interactive value to identify interactive packages?
  2008-08-06  9:22 [gentoo-dev] [RFC] New PROPERTIES=interactive value to identify interactive packages? Zac Medico
@ 2008-08-06  9:35 ` Alec Warner
  2008-08-06  9:59   ` Zac Medico
  2008-08-07  4:27 ` Jeremy Olexa
  1 sibling, 1 reply; 7+ messages in thread
From: Alec Warner @ 2008-08-06  9:35 UTC (permalink / raw
  To: gentoo-dev

On Wed, Aug 6, 2008 at 2:22 AM, Zac Medico <zmedico@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello again,
>
> Please consider a new PROPERTIES=interactive setting that allows an
> ebuild to indicate that it uses stdin and stdout for user
> interaction sometime during the pkg_setup and/or src_unpack phases
> (similar to GLEP 52 [1]). This will be another use for the new
> PROPERTIES metadata variable that's been proposed for the
> implementation of live-sources [2] and virtual [3] PROPERTIES values.
>
> This is useful in cases when it might not be possible for the user
> to perform interaction with ebuilds, so they might decide to mask
> any ebuilds that exhibit this property. It can also be used to know
> in advance whether or not it's safe to run the pkg_setup and
> src_unpack ebuild phases in the background. This provides a solution
> for bug #233296 [4] by allowing exclusive access to stdin and stdout
> to be guaranteed during pkg_setup and src_unpack phases.  We might
> also consider adding finer grained values of PROPERTIES such as
> interactive-setup, interactive-unpack, and interactive-preinst.
>
> Your comments will be appreciated.
>
> Thanks,
> Zac

Just to be clear; PROPERTIES is a space separated list of items correct?

>
> [1] http://www.gentoo.org/proj/en/glep/glep-0052.html
> [2]
> http://archives.gentoo.org/gentoo-dev/msg_187585c5d49b69034183719ff473710d.xml
> [3] http://article.gmane.org/gmane.linux.gentoo.devel/57610
> [4] http://bugs.gentoo.org/show_bug.cgi?id=233296
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAkiZbWwACgkQ/ejvha5XGaNOxwCdHdmNrDNQdH3PHtciQKINZHRv
> 6goAnjPL1i3Qwj3cs3lcC+v027TtRFPQ
> =RZBV
> -----END PGP SIGNATURE-----
>
>



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [gentoo-dev] [RFC] New PROPERTIES=interactive value to identify interactive packages?
  2008-08-06  9:35 ` Alec Warner
@ 2008-08-06  9:59   ` Zac Medico
  0 siblings, 0 replies; 7+ messages in thread
From: Zac Medico @ 2008-08-06  9:59 UTC (permalink / raw
  To: gentoo-dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alec Warner wrote:
>> Just to be clear; PROPERTIES is a space separated list of items correct?

I was thinking that it might support the same syntax as RESTRICT,
which includes support for USE conditionals.

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiZdh0ACgkQ/ejvha5XGaPtyACgso0LNGGGgYdAFpNTusN63y3s
dxMAoPI5pgeHHEeIiJnGz/iHSqdECbMc
=0m6a
-----END PGP SIGNATURE-----



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [gentoo-dev] [RFC] New PROPERTIES=interactive value to identify interactive packages?
  2008-08-06  9:22 [gentoo-dev] [RFC] New PROPERTIES=interactive value to identify interactive packages? Zac Medico
  2008-08-06  9:35 ` Alec Warner
@ 2008-08-07  4:27 ` Jeremy Olexa
  2008-08-07  4:44   ` Alec Warner
  2008-08-07  5:34   ` Zac Medico
  1 sibling, 2 replies; 7+ messages in thread
From: Jeremy Olexa @ 2008-08-07  4:27 UTC (permalink / raw
  To: gentoo-dev

> Please consider a new PROPERTIES=interactive setting that allows an
> ebuild to indicate that it uses stdin and stdout for user

I don't think anyone will disagree with this one. The one problem that I 
see is that if the ebuild still doesn't have this value in it, portage 
will *look* like it has hung itself out to dry. I have no idea if this 
is easy to fix or not. If it is easy, then I still would like to propose 
that it gets sent to the foreground when in background mode. What will 
portage's behavior be when the user asks to be in background mode and 
there is an ebuild in the depgraph that has PROPERTIES=interactive? If 
it bails out, then the problem described above is moot (only if 
maintainers are diligent).

-Jeremy



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [gentoo-dev] [RFC] New PROPERTIES=interactive value to identify interactive packages?
  2008-08-07  4:27 ` Jeremy Olexa
@ 2008-08-07  4:44   ` Alec Warner
  2008-08-07  5:34   ` Zac Medico
  1 sibling, 0 replies; 7+ messages in thread
From: Alec Warner @ 2008-08-07  4:44 UTC (permalink / raw
  To: gentoo-dev

On Wed, Aug 6, 2008 at 9:27 PM, Jeremy Olexa <darkside@gentoo.org> wrote:
>> Please consider a new PROPERTIES=interactive setting that allows an
>> ebuild to indicate that it uses stdin and stdout for user
>
> I don't think anyone will disagree with this one. The one problem that I see
> is that if the ebuild still doesn't have this value in it, portage will
> *look* like it has hung itself out to dry. I have no idea if this is easy to
> fix or not. If it is easy, then I still would like to propose that it gets
> sent to the foreground when in background mode. What will portage's behavior
> be when the user asks to be in background mode and there is an ebuild in the
> depgraph that has PROPERTIES=interactive? If it bails out, then the problem
> described above is moot (only if maintainers are diligent).

The build will also fail if the maintainer is not diligent enough to
add proper packages to DEPEND;
I don't necessarily see how it makes that much difference adding more
things for them to do.

If you can propose a means to figure out if an ebuild is stuck waiting
on something or actually doing work then propose it;
otherwise I think this is good enough.

-alec

>
> -Jeremy
>
>



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [gentoo-dev] [RFC] New PROPERTIES=interactive value to identify interactive packages?
  2008-08-07  4:27 ` Jeremy Olexa
  2008-08-07  4:44   ` Alec Warner
@ 2008-08-07  5:34   ` Zac Medico
  2008-08-07 13:15     ` Jeremy Olexa
  1 sibling, 1 reply; 7+ messages in thread
From: Zac Medico @ 2008-08-07  5:34 UTC (permalink / raw
  To: gentoo-dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremy Olexa wrote:
>> Please consider a new PROPERTIES=interactive setting that allows an
>> ebuild to indicate that it uses stdin and stdout for user
> 
> I don't think anyone will disagree with this one. The one problem that I
> see is that if the ebuild still doesn't have this value in it, portage
> will *look* like it has hung itself out to dry. I have no idea if this
> is easy to fix or not. If it is easy, then I still would like to propose
> that it gets sent to the foreground when in background mode.

We can use standard job control functions such as tcsetpgrp() to put
processes in the background and then detect when they're sent a
SIGTTIN signal in order to know that they've attempted to read from
stdin.

However, it's still useful to have PROPERTIES=interactive as a means
have knowledge of this behavior in advance, in case the user would
like to mask such ebuilds.

It also simplifies implementation details a bit if the package
manager can just grant exclusive stdio access in advance rather than
having to detect it when it happens and then having to update the
display from a saved output buffer or telling the application to
redraw itself (like dtach [1] does with Ctrl+L code) or whatnot.

> What will
> portage's behavior be when the user asks to be in background mode and
> there is an ebuild in the depgraph that has PROPERTIES=interactive?

I was planning to add some option for masking those, like
- --exclude-property=interactive or something like that. That would
mask the package so that it wouldn't be be included in the depgraph
unless it happens to be installed already.

> If
> it bails out, then the problem described above is moot (only if
> maintainers are diligent).

Like Alec said, I don't think this is a difficult thing to get right
and even if the maintainer doesn't get it right initially then it's
not something that's very difficult to spot and fix. More elusive
bugs certainly do exist. That said, I still would like to make use
of the standard job control functions to detect and handle cases
like that. However, that does not entirely preclude the usefulness
of the knowledge that PROPERTIES=interactive is intended to provide.

> -Jeremy
> 
> 

[1]
http://www.opengroup.org/onlinepubs/009695399/functions/tcsetpgrp.html
[2] http://dtach.sourceforge.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiaiWwACgkQ/ejvha5XGaMTMQCfS9IoGqHN8ehDpekir2VSO1+7
ELkAn1NJp7HJIQKu0hkC+CVXd7pwWF8c
=PQwl
-----END PGP SIGNATURE-----



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [gentoo-dev] [RFC] New PROPERTIES=interactive value to identify interactive packages?
  2008-08-07  5:34   ` Zac Medico
@ 2008-08-07 13:15     ` Jeremy Olexa
  0 siblings, 0 replies; 7+ messages in thread
From: Jeremy Olexa @ 2008-08-07 13:15 UTC (permalink / raw
  To: gentoo-dev

Zac Medico wrote:

> Like Alec said, I don't think this is a difficult thing to get right
> and even if the maintainer doesn't get it right initially then it's
> not something that's very difficult to spot and fix. More elusive
> bugs certainly do exist. That said, I still would like to make use
> of the standard job control functions to detect and handle cases
> like that. However, that does not entirely preclude the usefulness
> of the knowledge that PROPERTIES=interactive is intended to provide.


I agree with all the points presented. Sounds like you have a pretty 
good plan here.

Thanks,
-Jeremy



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2008-08-07 13:17 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-06  9:22 [gentoo-dev] [RFC] New PROPERTIES=interactive value to identify interactive packages? Zac Medico
2008-08-06  9:35 ` Alec Warner
2008-08-06  9:59   ` Zac Medico
2008-08-07  4:27 ` Jeremy Olexa
2008-08-07  4:44   ` Alec Warner
2008-08-07  5:34   ` Zac Medico
2008-08-07 13:15     ` Jeremy Olexa

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox