On Fri, 12 Jan 2007 14:05:49 +0100 Harald van Dijk <[EMAIL PROTECTED]> wrote: | 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.
And noauto and noclean do have specific genuine use, so it's not a
fair comparison.
| > 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.)
Except that Portage doesn't do automatic dependency disabling for
non-required packages that are masked.
| > 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.
You miss the point (I explained it elsewhere in the thread). Turning on
ACCEPT_RESTRICT=fetch will not behave the sane way if a
fetch-restricted package has had all its ${A} things downloaded. It
will still show up as masked, which is not desired behaviour.
--
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
