On Fri, Jan 12, 2007 at 12:19:18PM +0000, Ciaran McCreesh wrote: > On Fri, 12 Jan 2007 13:04:21 +0100 Harald van Dijk <[EMAIL PROTECTED]> > wrote: > | On Fri, Jan 12, 2007 at 11:55:44AM +0000, Ciaran McCreesh wrote: > | > On Fri, 12 Jan 2007 12:41:27 +0100 Harald van Dijk > | > <[EMAIL PROTECTED]> wrote: > | > | I don't think anyone was planning on encouraging people to mess > | > | with ACCEPT_RESTRICT if it gets implemented. > | > > | > Implementing it *is* encouraging people to mess with it. > | > | Just like people are encouraged to use FEATURES="noauto noclean"? > | Implementing it is not encouraging people to mess with it. > > 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? You can't group all features together in your logic, just because they share a variable. Please reconsider the point I tried to make. > | 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... -- [email protected] mailing list
