Shmuel Fomberg <shmuelfomb...@gmail.com> writes: > On Sun, Nov 11, 2012 at 4:51 PM, Andreas Koenig wrote: > >> >> > as a module user I don't really care why it failed to install - it is as >> > unusable to me as any other problem. >> > as a module author, I would like to know if my dependencies are not >> > dependable. >> >> This reasoning is correct, the question is how to deal with it. The >> single outstanding problem with this aspect of the dependency chain >> is the multi dimensional version dependency. A module with 64 direct >> and indirect dependencies is not rare. And the dependencies may all >> have had, say, 16 different versions on cpan. Gives easily 1024 ways >> to fail on a dependency. And among these there is a plentitude of >> irrelevant combinations. Or, as David Golden has put it: noise. >> > > Most of the modules does not change frequently,
That's a wrong assumption. Might apply for single cases but not in general. > and isn't that what cpan testers are about - to test multiple > combinations? A matrix like http://matrix.cpantesters.org/?dist=Data-DPath-0.47 potentially covers 500 combinations. And they are only comprehensible because they are in 2 dimensions. What you want adds new dimensions, a hypercube of the test matrix. That's where noise starts. > Let's take as a sample case Test::Class. It have a meaningless test > fail, a patch waiting in the RT, and a lot of modules depending on it. > How can I find the list of modules that directly depend on it? > metacpan's reverse-dep give indirect deps too. I will file a bug to > all of them, and let's see what will happen. That's a great example, really. Because you already *have* the issue and patch available. Why would you inform all the dependent modules if the root cause is already known? From a single RT ticket which needs to be pushed you want to multiply that onto all affected modules? By that rationale a bug in a Perl core module would require a ticket in all 20_000 CPAN distros. Better ask the author of the stalled ticket about co-maintainership or help him otherwise to bring that issue forward, eg. test it on your own in several combinations, document the results in the ticket, do that again with other prominent dependent modules, etc. Kind regards, Steffen -- Steffen Schwigon <s...@renormalist.net> Perl benchmarks <http://perlformance.net> Dresden Perl Mongers <http://dresden-pm.org/>
