Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 151113 - interactive ebuilds in the tree
Summary: interactive ebuilds in the tree
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Other
: High normal with 1 vote (vote)
Assignee: Portage team
URL: http://archives.gentoo.org/gentoo-dev...
Whiteboard:
Keywords:
: 58195 151101 153761 (view as bug list)
Depends on: 249100
Blocks: 155723 233296
  Show dependency tree
 
Reported: 2006-10-13 01:05 UTC by Evil Compile Person
Modified: 2012-03-25 14:57 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Evil Compile Person 2006-10-13 01:05:54 UTC
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
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2006-10-13 01:21:54 UTC
*** Bug 151101 has been marked as a duplicate of this bug. ***
Comment 2 Chris Gianelloni (RETIRED) gentoo-dev 2006-10-13 06:52:51 UTC
...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?
Comment 3 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2006-10-13 07:29:07 UTC
(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.

Comment 4 Zac Medico gentoo-dev 2006-10-13 12:38:59 UTC
(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...
Comment 5 Marius Mauch (RETIRED) gentoo-dev 2006-10-13 16:36:03 UTC
(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
Comment 6 Chris Gianelloni (RETIRED) gentoo-dev 2006-10-16 06:59:31 UTC
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.
Comment 7 Zac Medico gentoo-dev 2006-10-21 21:38:08 UTC
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.
Comment 8 Zac Medico gentoo-dev 2006-11-03 02:24:00 UTC
*** Bug 153761 has been marked as a duplicate of this bug. ***
Comment 9 Marius Mauch (RETIRED) gentoo-dev 2007-01-10 06:44:34 UTC
*** Bug 58195 has been marked as a duplicate of this bug. ***
Comment 10 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2007-04-15 01:34:05 UTC
(In reply to comment #7)
> Is RESTRICT="unattended" a good name for this?

Maybe RESTRICT="interpassive"? "interpassive" is etymological opposite of "interactive".
Comment 11 Marius Mauch (RETIRED) gentoo-dev 2007-06-06 00:37:25 UTC
For the record, Glep 52 has been withdrawn in favor of an ebuild function that's called at dependency calculation.
Comment 12 Steve L 2007-09-24 13:11:20 UTC
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."
Comment 13 Marius Mauch (RETIRED) gentoo-dev 2008-03-03 22:07:57 UTC
(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.
Comment 14 Steve L 2008-03-04 17:09:01 UTC
(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.
Comment 15 Marius Mauch (RETIRED) gentoo-dev 2008-03-04 21:04:37 UTC
(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.
Comment 16 Zac Medico gentoo-dev 2008-09-26 18:14:23 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 17 MATSUU Takuto (RETIRED) gentoo-dev 2008-11-22 02:10:08 UTC
fixed app-i18n/atokx2 and app-i18n/atokx3.
Comment 18 Zac Medico gentoo-dev 2010-03-03 11:34:12 UTC
We have a migration path away from check_license now:

http://archives.gentoo.org/gentoo-dev/msg_936df20dac8cef7ded4e75804d404b7a.xml

With portage-2.1.8 and 2.2_rc64, repoman will produce a deprecation warning for check_license calls in EAPI 3 or later.