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.
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.
