srj@unc.edu via RT wrote:
Show quoted text>> What would that message say?
>
> I'm not familiar with how much control the CPAN install shell has relative to the package
> installed
Almost none, by design.
Show quoted text> but if you can detect failure due to the bad AutoInstall module, perhaps something like:
The irony is that ExtUtils::AutoInstall is completely superfluous when
installing under the CPAN shell. It's designed to help users who are *not*
using the CPAN shell.
Show quoted text> "Failed to build the module [the_module], probably due to problems with the authors use of
> an [old|deprecated|broken description + version#] of the module Module::AutoInstall". As a
> work around, you can try installing Module::AutoInstall, [instructions on how to clear the old
> install, as mentioned above], and then try again to install the module. If that works, please
> report this as a bug to [url for module bug page] if not already listed there."
>
> Where [...] indicate runtime stuff, or details I don't know. This gets the user over the
> problem, gives them a test to verify the source of the bug, and if sufficiently motivated lets
> them know it is worthy of a bug report to the author, not CPAN in general. As installing
> generates a lot of information while building, this should be the last or nearly the last
> message. I'm assuming the work around I used is actually a good idea...
While it would be nice if the CPAN shell could walk the user through such
issues, it really can't (and shouldn't) make much in the way of assumptions
about how the distribution is put together.
In the interest of full disclosure, I hate that Module::Install will not use a
newer, installed version of its bundled modules and am disinclined to twist
things around to support it when that breaks.
Show quoted text> Alternatively, someone could write a script to test this for each module already existing and
> either auto-file a bug for each failing module - politely, as it will probably be a repeated bug
> on some lists, or do so manually, depending on how many modules fail and how often this
> will recur with new releases of Module::AutoInstall. I am not a web person, but it seems like
> this kind of code would be straight-forward, if not simple, to do. Especially if the problem
> can be detected based on package contents without doing an install.
Sounds like you're volunteering. :)
Some things to help you out are:
CPAN::Mini::Extract can download and scan all the latest modules on CPAN for you.
Every distribution can be emailed a bug report via
bug-<distribution_name>@rt.cpan.org So bug-CPAN-Mini-Extract@rt.cpan.org for
example.
That should be all you need to do your scan and mail the authors.
--
170. Not allowed to “defect” to OPFOR during training missions.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/