Yeah the "soft" thing was meant as "do this unless something breaks, then
do it otherwise"

On Wed, Feb 10, 2016 at 8:57 PM, Kent Fredric <kentfred...@gmail.com> wrote:

> On 11 February 2016 at 15:51, Rich Freeman <ri...@gentoo.org> wrote:
> > In this case you just wouldn't enable python 2.7 support, but you
> > wouldn't disable it either.  Portage would just pull it in where it is
> > needed.
>
>
> But you still need a mechanism in place if you *dont* want that to happen.
>
> I might choose to forbid python2.7 support, and portage really
> shouldn't "auto enable" python 2.7 support if I've explicitly
> indicated I don't want python 2.7 support.
>
> Unless of course you're suggesting "USE=-python_targets_python2_7"
> would not be "auto-enableable"
>
> But then you're *still* requiring a tri-state USE.
>
> USE="-foo" + IUSE="+foo" => "-foo"  => autouse enables foo if required
> USE=""  + IUSE="+foo" => "foo"        => standard EFFECTIVE_USE="foo"
> USE="foo" + IUSE = "+foo" => "foo" => standard EFFECTIVE_USE="foo"
> USE="-foo" + IUSE="foo" => "-foo"  => autouse enables foo if required
> USE="" + IUSE="foo" => "-foo"         => autouse enables foo if required
> USE="foo"  + IUSE="foo" => "foo"   => standard EFFECTIVE_USE="foo"
>
>
> So the logic composing USE + IUSE has to change in generating the
> effective USE set so that USE + IUSE can emit a 3rd and 4th state.
>
> USE="-foo" + IUSE="+foo" => "-foo!!"  => autouse fails if foo is required
> USE=""  + IUSE="+foo" => "foo"        =>  standard
> EFFECTIVE_USE="foo", auto-unuses foo if blocked by a dep
> USE="foo" + IUSE = "+foo" => "foo!!" => standard EFFECTIVE_USE="foo",
> fails if foo is "blocked" by a dep
> USE="-foo" + IUSE="foo" => "-foo!!"  => autouse fails if foo is required
> USE="" + IUSE="foo" => "-foo"         => autouse enables foo if required
> USE="foo"  + IUSE="foo" => "foo!!"   => standard EFFECTIVE_USE="foo",
> fails if "foo" is blocked by a dep.
>
>
> Mentally keeping track of this accounting magic would be complicating
> matters.
>
> --
> Kent
>
> KENTNL - https://metacpan.org/author/KENTNL
>
>

Reply via email to