That is, provided it works. Which, on many machines and systems I have tried, it simply does not.
This wouldn’t be so bad, if a whole slew of modules that happily built dependencies upon it, didn’t require it for their own testing.
This is related to the installation radius problem. In SuSE, I can’t make the gnome-VFS rpm go away, without also removing aaa_base, which happens to have all the nice things I want, like the OS base. Which means that I am stuck with a larger dependency radius than I want or need thanks to packaging. I am forced to install more stuff than I need.
Which increases the size of my disk footprint. It increases the potential attack surface (more things mean more possible attacks).
What I could do is simply create a reaper code to run through the post-installed file system and cull the herd (or tree) to what I need, regardless of the RPMs. Brute force, painful, have to reverse engineer distros … not a happy thing.
How do I handle the WWW::Mechanize situation? Since it won’t run its tests correctly, every last thing that depends upon it, may in fact be broken (and this is a huge swath of things) due to tests failing … ironically, not because the modules themselves are problematic. That is, the modules may work (or maybe not). But I can’t tell.
So if I create a module Foo, that uses WWW::Mechanize to test itself, and WWW::Mechanize is broken, then Foo will call itself broken, as it can’t really distinguish between a broken Foo and a broken WWW::Mechanize.
Again, in defense of the module writer, it is a complex task. It is hard to get this working, and I respect them for doing the work. Its just the hardwired tests to wikipedia really don’t fly on internal customer machines with no easy access to the web. It would be far better to have a miniserver set up as part of the testing, and see if it can grab pages from itself.