Task-Weaken checks at its built-time (in Makefile.PL) whether Scalar::Util's weaken function is present ... and does nothing at runtime. "some operating system distributions only include the pure-Perl versions, don't include the XS version, and so weaken is then "missing"" Our perl and Scalar-List-Utils include the XS version. I think we shouldn't depend on it and i've cleaned the tree in May 2009. http://tinderbox.x86.dev.gentoo.org/misc/dindex/dev-perl/Task-Weaken
tove: as a general extension question, I'm wondering about making a list of perl packages that: 1. Should not be listed in DEPEND or RDEPEND at all. 2. Valid in DEPEND but not RDEPEND. Per your comments here, Task-Weaken is a good candidate for the first. I'll remove it from the Moose stuff.
(In reply to comment #1) > tove: as a general extension question, I'm wondering about making a list of > perl packages that: > 1. Should not be listed in DEPEND or RDEPEND at all. > 2. Valid in DEPEND but not RDEPEND. No fixed rules, only suspicious dependencies: ad 1) - dev-perl/Module-Install: if needed, packaging is probably broken? - anything from perl-core/* (if not in virtual/perl-* (or perl-core/*, but that's probably not correct too)) ad 2) - virtual/perl-Module-Build - dev-perl/extutils-pkgconfig, dev-perl/extutils-depends Probably all ExtUtils-* ? - Test-* modules in non-Test modules.
zmedico: repoman questions here. Wondering how to start plugging in some checks to detect badness in Perl ebuilds (mainly based on stuff that shouldn't be in [R]DEPEND).
Repoman already has a list of packages for it's RDEPEND.suspect check. We can use that, and also add a DEPEND.suspect category.
So why is Task-Weaken still in portage tree then?
Decent ideas here, I've come across most of them in more recent bug reports... :P We really need some sort of repoman plugin structure. Anyway no point to keep this dinosaur open.
That repoman plugin system is in progress now. We are currently in stage1 of what I planned as a 3 stage process for the repoman rewrite. stage1: split out the tests into a decent python structure. minimal code changes, make the tests into classes with standard functions to call them. move any vcs specific code to an in class sudo plugin system (for later proper VCS plugin system creation). debug, merge into master. stage2 creation of proper plugin systems for tests and vcs specific items. stage3 code optimizations, further rewrites, ...
