On Tue, 3 Jul 2012 21:05:46 +1200 Kent Fredric <kentfred...@gmail.com> wrote:
> 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. Yes. Which simply means that something is broken with dependencies. And by that I mean that either: a) || ( a b ) should be || ( b a ), to actually state what perl does, b) perl should be modified to work like our deps specify. > > 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". If user intentionally installs an older version, he should be aware that the result will be having the older version rather than the newer one. I think we shouldn't prevent that. > > 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 :/ Nevermind it. It was an assumption that a & b could be fine together later on but I'm not sure if it was really on the topic. > > 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. I don't really think we allow blockers to enforce upgrades/downgrades. > 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". Do you actually need to do that? All those ebuilds will depend on perl with minimal version number necessary for the package to build. If perl is older, the package will be built normally. If perl is newer, the package will install a no-op. It's fine unless you consider downgrading perl. But thinking about it... any upgrade or downgrade of perl breaks all the modules anyway. About other package dependencies, they're probably fine in both cases. If a newer perl provides the particular module, all its dependencies have to be satisfied in perl anyway. So it will just pull more 'virtuals'. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
