-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/07/12 05:05 AM, Kent Fredric 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. > >> >> Doesn't perl-cleaner handle perl upgrades for this? And the >> tested ABI_SLOTs should help with that too. >
Just to add a note in here, since the perl stuff is one of the first things I converted to 4-slot-abi, unfortunately, no it doesn't seem that ABI slots are going to help with this. Sub-slots will trigger rebuilds of anything built against an older perl when it's upgraded, but it seems to have no effect on any of the virtual/perl-* stuff. The only effect it may have is giving the ability to specify perl versions via slots instead of wildcard-versions (ie: =dev-lang/perl-5.16* would become dev-lang/perl:0/5.16 ) Some of these perl virtuals have rather convoluted perl versions (like, all 5.16, all 5.14, only 2 versions of 5.12, and a particular version of 5.10), and so I don't think sub-slot deps will help the situation here as i don't think we could align the sub-slot bumps by feature set, at least not right now.. One thing that sub-slots ARE doing, though, is they are (as far as I can tell) not triggering rebuilds for any installed packages that are superseded (and therefore their virtual is now satisfied) by the newer perl. I realize this didn't occur before either, but I don't know if perl-cleaner handled their removal or not (or if perl-cleaner actually rebuilt them)? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAk/zClIACgkQ2ugaI38ACPDIPwEAkd6hlmoMQ4SRhvkttoyP11ih EKoR+tUNaMEqeb87T34A/irG+h8tPolXKsJQtEoRKr5xIGvWDYT83LlmV4fbOwui =Vf92 -----END PGP SIGNATURE-----
