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". | > | 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? And what about the time spent explaining to everyone why fetch can't be used in ACCEPT_RESTRICT to get the results they expect 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. -- Ciaran McCreesh Mail : ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/
signature.asc
Description: PGP signature
