| Summary: | detecting perl-mod ebuild QA problems | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Torsten Veller (RETIRED) <tove> |
| Component: | New packages | Assignee: | Gentoo Perl team <perl> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | dev-portage |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Torsten Veller (RETIRED)
2009-11-22 20:40:55 UTC
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, ...
|