| 1 |
On Fri, Jan 12, 2007 at 12:46:58PM +0000, Ciaran McCreesh wrote: |
| 2 |
> On Fri, 12 Jan 2007 13:30:11 +0100 Harald van Dijk <truedfx@g.o> |
| 3 |
> wrote: |
| 4 |
> | > FEATURES has legitimate values. The feature as a whole is useful, |
| 5 |
> | > even if some of the options have very restricted target audiences. |
| 6 |
> | |
| 7 |
> | So if ACCEPT_* were implemented in a way that lets you write |
| 8 |
> | ACCEPT="keyword:~x86 -license:QPL-1.0 restrict:sandbox" |
| 9 |
> | you'd have no problem? After all, ACCEPT as a whole is useful, right? |
| 10 |
> |
| 11 |
> If ACCEPT were implemented that way, and there were no additional code |
| 12 |
> involved in making restrict work in it, then it would be reduced from |
| 13 |
> "silly misfeature" to "something that works by fluke but that you |
| 14 |
> shouldn't do". |
| 15 |
|
| 16 |
FEATURES="noauto noclean" do not work by fluke. I'll ask you a second |
| 17 |
time to try to reconsider the point I was making. |
| 18 |
|
| 19 |
> | > | As for the legitimate use, I won't try to convince you that there |
| 20 |
> | > | are legitimate uses, but rather, even if it is silly, what does |
| 21 |
> | > | it matter to you? |
| 22 |
> | > |
| 23 |
> | > It matters in that there's even more time being spent going off on |
| 24 |
> | > completely the wrong track that would be of more use elsewhere. |
| 25 |
> | |
| 26 |
> | ACCEPT_RESTRICT is trivial to implement and to maintain, even moreso |
| 27 |
> | if you combine the code for it with that for ACCEPT_LICENSE. More |
| 28 |
> | time has been spent on this thread than would have to be on the |
| 29 |
> | code... |
| 30 |
> |
| 31 |
> And what about the time spent arguing with users who start demanding |
| 32 |
> that your package stop depping upon some random other package that |
| 33 |
> happens to need userpriv turned off? |
| 34 |
|
| 35 |
I'd like to give users a little bit more credit than to ask for |
| 36 |
dependencies on required packages to be dropped. (And as for |
| 37 |
dependencies on non-required packages, generally speaking, they should |
| 38 |
already be optional dependencies, or not dependencies at all.) |
| 39 |
|
| 40 |
> And what about the time spent |
| 41 |
> explaining to everyone why fetch can't be used in ACCEPT_RESTRICT to |
| 42 |
> get the results they expect |
| 43 |
|
| 44 |
Presumably, the default for ACCEPT_RESTRICT would include all possible |
| 45 |
values, so the case to consider is ACCEPT_RESTRICT=-fetch, which I can |
| 46 |
only imagine to work in one way. |
| 47 |
|
| 48 |
> and why userpriv and sandbox are not |
| 49 |
> dangerous? |
| 50 |
> |
| 51 |
> Just because a feature *can* be added doesn't mean it *should*, no |
| 52 |
> matter how trivial it is. |
| 53 |
|
| 54 |
Correct, that reason by itself is not enough. My reply specifically |
| 55 |
addressed your comment, it was not a complete argument /for/ |
| 56 |
ACCEPT_RESTRICT. |
| 57 |
-- |
| 58 |
gentoo-dev@g.o mailing list |
Archives