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

On 3 July 2012 20:24, Michał Górny <mgorny@gentoo.org> wrote:

eix Module-Metadata
[I] perl-core/Module-Metadata
Available versions: ~1.0.3 ~1.0.4 ~1.0.5 1.0.6 ~1.0.9 <
not unmasked by --autounmask
Installed versions: 1.0.6(15:59:00 06/26/12)
Homepage: http://search.cpan.org/dist/Module-Metadata/
Description: Gather package and POD information from perl
module files

[I] virtual/perl-Module-Metadata
Available versions: ~1.0.3 ~1.0.4-r2 ~1.0.5 1.0.6 (~)1.0.9-r1
<-- Unmasked by --autounmask
Installed versions: 1.0.9-r1(09:37:51 07/02/12)
Description: Virtual for Module-Metadata

perl-Module-Metadata-1.0.9.ebuild

RDEPEND="|| ( =dev-lang/perl-5.16* ~perl-core/${PN#perl-}-${PV} )"

It appears yes, --depclean *will* reap perl-core/* in this scenario (
portage 2.2.0_alpha114 )

Just I don't tend to use --depclean an awful lot. Usually, I don't
expect to have to use --depclean to avoid a somewhat "broken" system.

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

ABI_SLOT may be able to help, but the problem is that installing
perl-core/foo-1.0 on perl-5.10 which ships foo-2.0 , is 100% fine.

It will just shadow the 2.0 version with the 1.0 version, and assume
"that is what you want", while the virtual is trying to convey "That
is not what we want".

And perl-cleaner doesn't have any code to handle this scenario last I
checked. You can't even work out what is the "right" installation
scenario without first knowing "what do installed packages want". If
"installed packages want version foo to be smaller than 2.0" then
perl-core/foo-1.0 being installed on perl-5.10 is "Fine" . For this,
they would depend on "<virtual/perl-foo-2" .

In essence, you can't tell if the right perl-core/* is installed
without first looking that what virtual is installed.

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.

Given

C = " ^^( a b )" and you had "A and C" in your world, and you wanted
to install B, portage would tell you that to do that, you would have
to remove either A or C. ( Yay, the communicative property of XOR :D
)

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

I can't parse this statement. Sorry :/

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

No, perl would never be removed, not unless the ^^( ) was simply

"^^( perl foo )"

In practice, it would be "^^( =dev-lang/perl-5.16* =foo-5.0 )" which
would mean

a) remove foo
b) downgrade/upgrade dev-lang/perl

of course, I have noticed a fly in my ointment, in that this logic
would mean this blocker could be avoided by down/upgrading foo, which
is precisely what we want to avoid. So its back to the drawing board.


If we were to discard what we currently know about dependencies for a
moment, a dep spec of


perl-Foo-5.0:

if ( =dev-lang/perl-5.10.0 ) {
block versions of perl-core/Foo that are not 5.0
# Because if somebody wants to install perl-core/Foo-5.0 in
perl-5.10 , thats fine, its pointless, but its fine
# because perl-core/Foo-5.0 'provides' Foo-5.0, as does
perl-5.10, so this is satisfactory behaviour
} else {
install perl-core/Foo-5.0 and only perl-core/Foo-5.0
# Because something has stated that it "wants" Foo-5.0 for some reason,
# So we must deliver it at all costs. If its not shipped in
perl, then we provide it.
}

It would be nice to be able to just say "Fine, how about we just
always install from perl-core/".

Which hits the road block as soon as upstream release dev-lang/perl
with Foo-5.01 , and Foo-5.01 is not available on CPAN. ( Sometimes its
a 'dev' release, other times its not ) .

Better approaches welcome.

I have thought of scrapping the virtuals entirely and handling it so
that things depend on perl-core/* instead, and perl-core can just
dynamically decide at install time whether or not it needs to no-op (
and sometimes perl-core/* will need to hard depend on perl and just
install nothing ).

This seems a simpler approach until you consider the problem of "How
do we determine dependencies for this ebuild".

Messy. :/

With API_SLOTS I guess we can (maybe) have api-slot conditional
SRC_URI and DEPEND values,

# Not real code, just pesudocode
SRC_URI=" ! API-Perl-5.10 ? ( . ) "

DEPEND=" ! API-Perl-5.10 ? ( . ) "

Or some shit like that.

If we're really really keen, we might be able to throw it together
with some USE_EXPAND , it might be tidier, it might not be.


Kent

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

http://kent-fredric.fox.geek.nz