1 |
Alec Warner wrote: |
2 |
>>>> Title: RESTRICT=interactive |
3 |
>>> I'd say it's good idea, although isn't RESTRICT=interactive a slight |
4 |
>>> misnomer? You are enforcing interactiveness, not restricting it :) |
5 |
>>> Although RESTRICT="non-interactive" sounds weird too, and introducing |
6 |
>>> new variable would be bloating. |
7 |
> |
8 |
> If you look at every other RESTRICT match you will find they follow a |
9 |
> similar "backwards" pattern. |
10 |
|
11 |
No, all the other ones make sense when you read them as "restrict |
12 |
(disallow) $foo-ing." |
13 |
|
14 |
> RESTRICT="fetch" -> turns off fetching |
15 |
> RESTRICT="strip" -> don't strip binaries |
16 |
> RESTRICT="test" -> Don't call pkg_test |
17 |
> RESTRICT="interactive" -> This ebuild is interactive. |
18 |
> |
19 |
> If you read it like you are placing a specific restriction: |
20 |
> "A {test,strip,fetch,interactive} restriction on the ebuild" |
21 |
> then the naming scheme makes a bit more sense. |
22 |
|
23 |
It still doesn't make sense. Restricting any other feature disallows it. |
24 |
Restricting interaction allows it. Find a word that's the antonym of |
25 |
interactive, and restrict that. |
26 |
|
27 |
This isn't a huge issue in the scope of the GLEP, but it is one that |
28 |
needs to get fixed. |
29 |
|
30 |
Thanks, |
31 |
Donnie |