On Fri, Jan 12, 2007 at 12:46:58PM +0000, Ciaran McCreesh wrote: > On Fri, 12 Jan 2007 13:30:11 +0100 Harald van Dijk <[EMAIL PROTECTED]> > wrote: > | > FEATURES has legitimate values. The feature as a whole is useful, > | > even if some of the options have very restricted target audiences. > | > | So if ACCEPT_* were implemented in a way that lets you write > | ACCEPT="keyword:~x86 -license:QPL-1.0 restrict:sandbox" > | you'd have no problem? After all, ACCEPT as a whole is useful, right? > > If ACCEPT were implemented that way, and there were no additional code > involved in making restrict work in it, then it would be reduced from > "silly misfeature" to "something that works by fluke but that you > shouldn't do".
FEATURES="noauto noclean" do not work by fluke. I'll ask you a second time to try to reconsider the point I was making. > | > | As for the legitimate use, I won't try to convince you that there > | > | are legitimate uses, but rather, even if it is silly, what does > | > | it matter to you? > | > > | > It matters in that there's even more time being spent going off on > | > completely the wrong track that would be of more use elsewhere. > | > | ACCEPT_RESTRICT is trivial to implement and to maintain, even moreso > | if you combine the code for it with that for ACCEPT_LICENSE. More > | time has been spent on this thread than would have to be on the > | code... > > And what about the time spent arguing with users who start demanding > that your package stop depping upon some random other package that > happens to need userpriv turned off? I'd like to give users a little bit more credit than to ask for dependencies on required packages to be dropped. (And as for dependencies on non-required packages, generally speaking, they should already be optional dependencies, or not dependencies at all.) > And what about the time spent > explaining to everyone why fetch can't be used in ACCEPT_RESTRICT to > get the results they expect Presumably, the default for ACCEPT_RESTRICT would include all possible values, so the case to consider is ACCEPT_RESTRICT=-fetch, which I can only imagine to work in one way. > and why userpriv and sandbox are not > dangerous? > > Just because a feature *can* be added doesn't mean it *should*, no > matter how trivial it is. Correct, that reason by itself is not enough. My reply specifically addressed your comment, it was not a complete argument /for/ ACCEPT_RESTRICT. -- [email protected] mailing list
