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

[Michał Górny]

On Tue, 3 Jul 2012 15:44:04 +1200
Kent Fredric <kentfredric@×××××.com> wrote:

> 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.

--depclean?

> 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.

Doesn't perl-cleaner handle perl upgrades for this? And the tested
ABI_SLOTs should help with that too.

> 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.

This is a really fragile approach, and is mostly a workaround
to the real issue. You want to say «I need *only* one of my
dependencies satisfied» while you actually get «if I'm installed, then
let every my dependency in those blocks actually block each other».

That's just impossible to achieve. Think of ^^ ( foo bar ). When
the package gets installed, foo is installed and bar is not. Then you
want to emerge bar. What should happen?

a) you want portage to refuse to do that. Why would it? AFAIU this
would no longer be a problem actually.

b) you want portage to do that. But you just forced it unmerge it? It
will install the previously made binary package and it's back...

c) you want portage to unmerge foo because the dep will now be
satisfied by bar. Wait... unmerge perl?

> 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.
>



-- 
Best regards,
Michał Górny