On Fri, Jan 12, 2007 at 05:19:02PM +0000, Ciaran McCreesh wrote:
> 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.
Again irrelevant to the point, since regardless of whether they have
some small valid use, they should not be recommended to users.
> | > 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.
Okay, that's a fair enough point; it's possible to make portage handle
that case nicer, and if ACCEPT_* (it also applies to LICENSE) has to
wait until it does, I won't object.
> | > 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.
I'm not sure what you mean.
With ACCEPT_RESTRICT=fetch, portage should behave as it currently does:
be quiet if the sources are available, complain if they're not. If
portage would always complain, yeah, that's bad, but I don't see why it
would do that.
With ACCEPT_RESTRICT=-fetch, you tell it you don't want packages with
RESTRICT=fetch, so portage /should/ complain regardless of whether the
sources are available.
--
[email protected] mailing list
