On 3 July 2012 20:24, Michał Górny <mgo...@gentoo.org> wrote: > > --depclean?
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