[gentoo-portage-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND

[Kent Fredric]

Firstly, we already have a ^^(  ) syntax for REQUIRED_USE , "one of,
but not more than one of".

However, to my knowledge, we don't have such for ebuilds.

Sure, there are ways of implementing this in ebuilds without this
notation, but they're a bit messy.

For instance, we seem to find the need for something like this in perl
virtuals,

|| (  =dev-lang/perl-$A  =perl-core/foo-$B )

However, this current form has its limitations:

1. If =perl-core/foo-$B  was previously installed, satisfying the
condition, and =dev-lang/perl-$A becomes installed, perl-core/foo-$B
then gets ignored, but its still left installed, and not cleaned.

2. Due to the nature of how perl works, any version installed from
perl-core/ will "shadow" the version installed by dev-lang/perl , so
that, despite the virtual being satisfied, the version of the code you
get is unsatisfactory from time to time. ie:

  dev-lang/perl-5.10  might provide  'quux-1.2.3'   , as will
perl-core/quux-1.2.3

If you were previously on perl-5.8 , ( which only shipped quux-1.1 ) ,
and had installed =virtual/perl-quux-1.2.2 ,  you would have to
install =perl-core/quux-1.2.2 to get "quux-1.2.2"

Along comes 5.10, and quux-1.2.3 , so we release   virtual/perl-quux-1.2.3

   || ( =dev-lang/perl-5.10  =perl-core/quux-1.2.3 )

^^ this does what we want most of the time, if you can install
perl-5.10, just do that to get quux 1.2.3, otherwise, install
quux-1.2.3 from perl-core .

However, in the above case, what happens is virtual/perl-quuux-1.2.3
is installed, which is satisfied by '=dev-lang/perl-5.10" , and
portage is happy with that.

And then you do 'perl -e 'use quux 1.2.3' # and it barfs saying 1.2.2
is still installed, which it is, because perl-core/quux-1.2.2 is still
installed, overshadowing the more recent one provided by dev-lang/perl

Ideally, what we want here is ^^(  ), or something like it, so that if
the earlier part is satisfied, latter parts are then removed.

You *can* represent the same logic with other mechanisms, but its much
much more complex to do so.

|| (
      (
            =dev-lang/perl-5.10
            !<perl-core/quux-1.2.3
            !>perl-core/quux-1.2.3
      )
      (
           !dev-lang/perl-5.10
           =perl-core/quux-1.2.3
      )
)

And I *think* that will do the right thing, I really have no idea.

The other approach of course is to make the blockers happen in
dev-lang/perl and perl-core/quux , but this has its own problems.

For instance, =dev-lang/perl *cannot* specify which versions of
perl-core/quux can and cannot be installed.  Because its not *perl*
that is trying to define what version is installed, but the virtual.

And perl-core/quux can't really block perl , because the whole point
of perl-core/quux is to be installed on perls other than the ones it
was shipped with.


^^(  ) seems to nicely help solve this problem, and it seems like an
oversight that we have OR , AND , and NOT  dependency rules, but not
XOR.

P.S. Blame Patrick for this message.

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"