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, and isn't that what cpan testers are about - to test multiple combinations? > > Of course, visiting the deps site can show this information, but if the > > author isn't aware of the problem, why would he visit it? > I would ask the corresponding question to you: what is it that stops you > from reporting to the author via RT? > I did that. Again and again. but can't I just install modules and expect them to work? I'm growing tired of that. > And finally, if a module author upload a new version, and this new > version > > have test failure, I think that it is possible to notify the authors of > > modules that depend on it without spamming them, but it is really tricky. > Fill the bugtrackers and keep track of the tickets yourself, so we can > learn from the experience. 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. Shmuel.
