| 1 |
On Sun, 08 Jul 2007 04:53:40 +0100 |
| 2 |
Steve Long <slong@××××××××××××××××××.uk> wrote: |
| 3 |
|
| 4 |
> I understand that games are a `special case', but why not make it a |
| 5 |
> RESTRICT=interact which would automatically mean repoman would not |
| 6 |
> allow the package into stable, and admins could easily weed such |
| 7 |
> packages out? That way any category could use the same thing for |
| 8 |
> packages with more restrictive licenses. (I'm not suggesting this |
| 9 |
> should be merged with fetch-restricted as I accept that some stable |
| 10 |
> Java packages have this set, and there's zero benefit in changing |
| 11 |
> them.) |
| 12 |
|
| 13 |
This isn't about stable or not stable, or about games being special. No |
| 14 |
ebuild _should_ be interactive, period. However in some cases there is |
| 15 |
no way to make it non-interactive, and the concentration of those cases |
| 16 |
is particulary high in the games category (mainly because of a lack of |
| 17 |
high quality OSS games). |
| 18 |
Oh, and I've withdrawn the RESTRICT idea as there is a better/more |
| 19 |
generic solution (not yet implemented though). |
| 20 |
|
| 21 |
> So yeah I guess it's encouragement, but if the policy is such |
| 22 |
> packages can never hit stable, where's the harm? A user has to |
| 23 |
> explicitly allow such a package (or run unstable in which case they |
| 24 |
> will be used to dealing with glitches ;) and scripts can still avoid |
| 25 |
> interactive packages. (And bear in mind, it's not just uis we're |
| 26 |
> talking about, but stuff like QA automation.) |
| 27 |
|
| 28 |
Again, interactivity isn't a criterium for a package becoming stable or |
| 29 |
not. |
| 30 |
|
| 31 |
Marius |
| 32 |
|
| 33 |
-- |
| 34 |
Marius Mauch <genone@g.o> |
| 35 |
-- |
| 36 |
gentoo-dev@g.o mailing list |
Archives