Bugzilla Bug 151113

The function cdrom_get_cds in eutils.eclass is by default interactive.

The following ebuilds use it and should be restricted (as discussed on IRC
either fetch or a new restrict like "fetch-cd" would be most excellent)

/usr/portage/app-emulation/vmware-workstation-tools/vmware-workstation-tools-5.5.1.ebuild
/usr/portage/app-emulation/vmware-workstation-tools/vmware-workstation-tools-4.5.3.ebuild
/usr/portage/app-i18n/atokx2/atokx2-17.0-r2.ebuild
/usr/portage/app-i18n/atokx2/atokx2-17.0.ebuild
/usr/portage/app-i18n/atokx2/atokx2-17.0-r1.ebuild
/usr/portage/eclass/vmware.eclass
/usr/portage/games-action/d1x/d1x-20040118.ebuild
/usr/portage/games-action/d2x/d2x-0.2.5-r2.ebuild
/usr/portage/games-action/rune/rune-1.07-r2.ebuild
/usr/portage/games-action/heretic2/heretic2-1.06c.ebuild
/usr/portage/games-action/fakk2/fakk2-1.02.ebuild
/usr/portage/games-action/descent3/descent3-1.4.0b-r1.ebuild
/usr/portage/games-action/heavygear2/heavygear2-1.0b.ebuild
/usr/portage/games-fps/ut2003-data/ut2003-data-2107.ebuild
/usr/portage/games-fps/ut2004-data/ut2004-data-3186-r3.ebuild
/usr/portage/games-fps/unreal-tournament-goty/unreal-tournament-goty-436.ebuild
/usr/portage/games-fps/unreal-tournament-goty/unreal-tournament-goty-451.ebuild
/usr/portage/games-fps/doom3-data/doom3-data-1.1.1282-r1.ebuild
/usr/portage/games-fps/quake3-teamarena/quake3-teamarena-1.32b.ebuild
/usr/portage/games-fps/tribes2/tribes2-25034.ebuild
/usr/portage/games-fps/unreal-tournament/unreal-tournament-436.ebuild
/usr/portage/games-fps/unreal-tournament/unreal-tournament-451.ebuild
/usr/portage/games-fps/soldieroffortune/soldieroffortune-1.06a.ebuild
/usr/portage/games-fps/quake1-data/quake1-data-2.40.ebuild
/usr/portage/games-fps/quake2-data/quake2-data-3.20.ebuild
/usr/portage/games-fps/quake3-data/quake3-data-1.32b.ebuild
/usr/portage/games-fps/quake4-data/quake4-data-1.0.2147.12.ebuild
/usr/portage/games-fps/unreal/unreal-226.ebuild
/usr/portage/games-fps/postal2/postal2-1409.2.ebuild
/usr/portage/games-fps/doom3-roe/doom3-roe-1.ebuild
/usr/portage/games-rpg/nwn/nwn-1.67.ebuild
/usr/portage/games-rpg/nwn-data/nwn-data-1.29.ebuild
/usr/portage/games-strategy/smac/smac-6.0a.ebuild
/usr/portage/games-strategy/darwinia/darwinia-1.3.0.ebuild
/usr/portage/games-strategy/darwinia/darwinia-1.4.0_beta9.ebuild
/usr/portage/games-strategy/dominions2/dominions2-2.16.ebuild
/usr/portage/games-strategy/heroes3/heroes3-1.3.1a-r2.ebuild
/usr/portage/games-strategy/heroes3/heroes3-1.3.1a-r1.ebuild
/usr/portage/games-strategy/wargus/wargus-2.1-r1.ebuild
/usr/portage/media-gfx/maya/maya-6.5.ebuild

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

...and?  Of *course* they're interactive.  They pull data from a CD.

All that adding some kind of restriction will do is piss off people trying to
use them, as adding a restriction won't resolve any problems with them being
interactive.  They are interactive by design and will stay that way.  What
exactly is this proposal about?  Making portage bomb out on interactive ebuilds
without some arbitrary FEATURE enabled?  How is that better than asking the
user for the CD and waiting for input?

(In reply to comment #2)
> ...and?  Of *course* they're interactive.  They pull data from a CD.
> 
> All that adding some kind of restriction will do is piss off people trying to
> use them, as adding a restriction won't resolve any problems with them being
> interactive.  They are interactive by design and will stay that way.  What
> exactly is this proposal about?  Making portage bomb out on interactive ebuilds
> without some arbitrary FEATURE enabled?  How is that better than asking the
> user for the CD and waiting for input?
> 

In particular, QA can't run checks against interactive ebuilds since they
are...by definition iteractive.

If I was enterprising I'd propose that you add

RESTRICT="interactive"

to your ebuild/eclasses so that we can then filter on it and ignore them.

Besides it's been a long standing stupid policy rule that users aren't supposed
to have to do anything when installing a package; although by that rule much
more of the tree is broken; so I'd rather just throw out the unworkable rule
and add in the metadata to just avoid some of the untestables.

(In reply to comment #3)
> RESTRICT="interactive"
> 
> to your ebuild/eclasses so that we can then filter on it and ignore them.

It allows them the be "masked", or at least notify the user up front that a
package in the merge list will require interaction.  If we must have
interactive ebuilds, RESTRICT="interactive" seems like a reasonable way to flag
them in the metadata.  If we're going to make this an official policy, then it
should be proposed on the gentoo-dev mailing list...

(In reply to comment #4)
> (In reply to comment #3)
> > RESTRICT="interactive"
> > 
> > to your ebuild/eclasses so that we can then filter on it and ignore them.
> 
> It allows them the be "masked", or at least notify the user up front that a
> package in the merge list will require interaction.  If we must have
> interactive ebuilds, RESTRICT="interactive" seems like a reasonable way to flag
> them in the metadata.  If we're going to make this an official policy, then it
> should be proposed on the gentoo-dev mailing list...

This is now GLEP 52

If/when portage gets support for this, feel free to add games/vmware/myself to
this bug again.  I'm likely going to take over Maya, since eradicator is
(mostly) dead and I actually use it.

I'm thinking about adding support for this (in addition to ACCEPT_LICENSE
support for bug 17367).  Is RESTRICT="unattended" a good name for this?  I'm
thinking that the user simply do FEATURES="unattended" in order to make portage
mask those ebuilds.

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

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

(In reply to comment #7)
> Is RESTRICT="unattended" a good name for this?

Maybe RESTRICT="interpassive"? "interpassive" is etymological opposite of
"interactive".

For the record, Glep 52 has been withdrawn in favor of an ebuild function
that's called at dependency calculation.

Given that the only con I can find mentioned in the GLEP page is that it could
technically be seen as requiring an EAPI bump, and that PMS is now back
in-house, is there any chance we could get this quick addition done? Apparently
there are 100 interactive ebuilds in stable atm, which makes life awfully
difficult for people trying to implement Enterprise support.

And I for one don't see the point in a p1ssing-mat^W^W turf war between games
and everyone else.

I'd also suggest that RESTRICT=interactive be used as per the code in the
patch, since "unattended" has the same logical problems as "no_gdb."

(In reply to comment #12)
> Given that the only con I can find mentioned in the GLEP page is that it could
> technically be seen as requiring an EAPI bump, and that PMS is now back
> in-house, is there any chance we could get this quick addition done? Apparently
> there are 100 interactive ebuilds in stable atm, which makes life awfully
> difficult for people trying to implement Enterprise support.

As mentioned on Irc, the problem with a binary flag is this often isn't a
binary state, but conditional on the system state (e.g. media is already in
place). If you want this implemented as a RESTRICT you're going to need some
policy in what cases it is applicable.

Btw, this came up while talking about it with Ciaranm (which was a requirement
of Grant to get this Glep accepted when I asked him about it), and as weird as
it may sound, in this particular case I agree with him that it would be better
handled with a pretend-time function.

I'm not completely against implementing it however, I just won't push for it,
so if you want this implemented you'll have to take the Glep to the council.

(In reply to comment #13)
> As mentioned on Irc, the problem with a binary flag is this often isn't a
> binary state, but conditional on the system state (e.g. media is already in
> place). If you want this implemented as a RESTRICT you're going to need some
> policy in what cases it is applicable.
>
It seems like there's two main cases: license acceptance, and media
availability. For media, there are two cases that I can see: where one disk is
required (which might be fulfilled at time of the emerge cmd) or where N disks
are required, which will always require the user to be present.

> Btw, this came up while talking about it with Ciaranm (which was a requirement
> of Grant to get this Glep accepted when I asked him about it), and as weird as
> it may sound, in this particular case I agree with him that it would be better
> handled with a pretend-time function.
>
I can see the need for such a function in the case where a medium is required,
but not where it's simple license-acceptance. Having some sort of metadata that
would indicate whether such a check is going to be required would also seem to
be more optimal?

> I'm not completely against implementing it however, I just won't push for it,
> so if you want this implemented you'll have to take the Glep to the council.
> 
Seems like we need to hash out how it should work, since the simple RESTRICT
won't deal with media. I was thinking maybe RESTRICT=interactive could be the
UI, with SOMEVAR=license|media in the ebuild. (IDK if that's more appropriate
in RESTRICT or something new, eg INTERACTIVE.) If it's a media one, there
should be a pkg_check (or w/e) function, which defaults to returning false for
interactivity required. (This would cover the cases where N disks are needed,
and also avoid sourcing where it's a license acceptance.)

Is there any standard way to check for the disk/should we be thinking of
providing one, or is it always down to the upstream installer?

All I want is to be able to know from the scripting side that interactivity
will be needed (similarly to F/f for fetch-restricted packages.) Having that
split into L and M makes sense, and scripts can then take appropriate action.
ATM if the user chooses a package/dep that requires license-acceptance (the
most common case) there's no way to know that short of grep'ping the ebuild for
a pkg_setup fn (which ofc won't take inherits into account). For tinderbox
devs, being able simply to specify a RESTRICT in the conf would also make
things a lot easier (about 250 masks apparently ;)

Thanks for your time.

(In reply to comment #14)
> It seems like there's two main cases: license acceptance, and media
> availability. For media, there are two cases that I can see: where one disk is
> required (which might be fulfilled at time of the emerge cmd) or where N disks
> are required, which will always require the user to be present.

License stuff is handled by ACCEPT_LICENSE with 2.2, check_license() is going
to die long-term.

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.

fixed app-i18n/atokx2 and app-i18n/atokx3.