| 1 |
>>> Title: RESTRICT=interactive |
| 2 |
>> I'd say it's good idea, although isn't RESTRICT=interactive a slight |
| 3 |
>> misnomer? You are enforcing interactiveness, not restricting it :) |
| 4 |
>> Although RESTRICT="non-interactive" sounds weird too, and introducing |
| 5 |
>> new variable would be bloating. |
| 6 |
|
| 7 |
If you look at every other RESTRICT match you will find they follow a |
| 8 |
similar "backwards" pattern. |
| 9 |
|
| 10 |
RESTRICT="fetch" -> turns off fetching |
| 11 |
RESTRICT="strip" -> don't strip binaries |
| 12 |
RESTRICT="test" -> Don't call pkg_test |
| 13 |
RESTRICT="interactive" -> This ebuild is interactive. |
| 14 |
|
| 15 |
If you read it like you are placing a specific restriction: |
| 16 |
"A {test,strip,fetch,interactive} restriction on the ebuild" |
| 17 |
then the naming scheme makes a bit more sense. |
| 18 |
|
| 19 |
Note above; we are not "enforcing interactiveness." Originally ebuilds |
| 20 |
were not supposed to be interactive; I would say it is still frowned |
| 21 |
upon by many people. However we have to accept that interactivity is |
| 22 |
required in certain instances and this metadata allows people to ignore |
| 23 |
these ebuilds when doing things like automated ebuild testing...unless |
| 24 |
the games team wants to donate all the media for their games ;) |
| 25 |
|
| 26 |
As for the GLEP itself; I'd like to see some patches, particularly for |
| 27 |
the resolver to show the restriction up front. Also a patch to the |
| 28 |
ebuild.5 manpage for RESTRICT=interactive prior to seeing the glep get |
| 29 |
approved. |
| 30 |
|
| 31 |
|
| 32 |
-- |
| 33 |
gentoo-dev@g.o mailing list |
Archives