Skip Menu |

This queue is for tickets about the CPAN CPAN distribution.

Report information
The Basics
Id: 33419
Status: open
Priority: 0/
Queue: CPAN

People
Owner: Nobody in particular
Requestors: srj [...] unc.edu
Cc:
AdminCc:

Bug Information
Severity: Unimportant
Broken in: 1.9205
Fixed in: (no value)



Subject: Undetected dependency required to build Getargs::Long - Module::AutoInstall
Using Perl 5.8.8 on Mac OS X 10.5.2 (Leopard). I had some problems installing Getargs::Long using a simple CPAN shell install. I quickly figured out the build was failing due to a missing module, Module::AutoInstall. This was not detected as a dependency, probably because this module has something to do with detecting dependencies. Since this seems to be a chicken/egg problem, I suspect it needs to be explicitly handled in some way. I wouldn't have bothered to comment on this as a bug, except after I figured out the missing module problem, installed it, and then tried to continue with the installation of Getargs::Long, I couldn't because of the previous failed install. Cleaning didn't work, as it had never built, so there was nothing to clean... Manually deleting the associated .cpan/build files fixed things. Since recovery from the failed install was problematic, it may be worth addressing this. PS - CPAN is great, thanks for all the work! Stuart R. Jefferys
Thanks for the ticket, Stuart. The point of the whole Module::Install family is that the user shall never install them. The historical reasoning for this was that there was a time where the authors of modules always had to force users to upgrade to the most recent ExtUtils::MakeMaker. Nowadays we have the opposite situation: users have to force authors to upgrade to the most recent Module::Install. I just filed ticket #33430 asking the author to upgrade. Your point that the installation was stuck and CPAN could not continue: that's what the fforce pragma is invented for. Whenever you have reason to believe that something went severely wrong during an installation and you would like to start it once again, say fforce test Getargs::Long this will start over in a new build directory up to the test phase. If it's ok, you can say 'install Getargs::Long' and it should install just fine.
From: srj [...] unc.edu
Thanks for the quick response. Is this author upgrade issued a common problem? Generating a clear message to this effect when the build failed would save time rerouting bug messages. At the expense coding time, of course. And thanks for the info about fforce. I have been using CPAN for years. Guess its time to re- RTFM. I avoided the command because the name scares me. I figure if I force something, It might break. And fforce sounds like REALLY forcing it. Knowing when and where to force something usually comes with experience from finding the limits the hard way. I might have tried force clean or fforce clean, if I had thought of it, since that is essentially what I did :) Stuart R. Jefferys
Subject: Re: [rt.cpan.org #33419] Undetected dependency required to build Getargs::Long - Module::AutoInstall
Date: Tue, 19 Feb 2008 12:13:10 -0800
To: bug-CPAN [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
srj@unc.edu via RT wrote: Show quoted text
> Thanks for the quick response. Is this author upgrade issued a common problem?
Yes, very much so. Show quoted text
> Generating a > clear message to this effect when the build failed would save time rerouting bug messages. At > the expense coding time, of course.
What would that message say? -- On error resume stupid
From: srj [...] unc.edu
On Tue Feb 19 15:22:53 2008, schwern@pobox.com wrote: Show quoted text
> srj@unc.edu via RT wrote:
> > Thanks for the quick response. Is this author upgrade issued a
> common problem? > > Yes, very much so. > >
> > Generating a > > clear message to this effect when the build failed would save time
> rerouting bug messages. At
> > the expense coding time, of course.
> > What would that message say? > >
I'm not familiar with how much control the CPAN install shell has relative to the package installed, but if you can detect failure due to the bad AutoInstall module, perhaps something like: "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... 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. Stuart R. Jefferys
Subject: Re: [rt.cpan.org #33419] Undetected dependency required to build Getargs::Long - Module::AutoInstall
Date: Tue, 19 Feb 2008 15:55:27 -0800
To: bug-CPAN [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
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/
Subject: Re: [rt.cpan.org #33419] Undetected dependency required to build Getargs::Long - Module::AutoInstall
Date: Wed, 20 Feb 2008 04:52:03 +0100
To: bug-CPAN [...] rt.cpan.org
From: andreas.koenig.7os6VVqR [...] franz.ak.mind.de (Andreas J. Koenig)
Show quoted text
>>>>> On Tue, 19 Feb 2008 18:56:30 -0500, "Michael G Schwern via RT" <bug-CPAN@rt.cpan.org> said:
Show quoted text
> 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.
Show quoted text
> That should be all you need to do your scan and mail the authors.
Beware to filter duplicates *manually*. You do not want to send reports to authors who have already an open ticket on the issue. -- andreas
Subject: Re: [rt.cpan.org #33419] Undetected dependency required to build Getargs::Long - Module::AutoInstall
Date: Thu, 21 Feb 2008 17:55:28 -0500
To: bug-CPAN [...] rt.cpan.org
From: Stuart Jefferys <srj [...] unc.edu>
Ok. I'll see what time I can fit in. Is there a better forum to post questions I might have to? On Feb 19, 2008, at 10:52 PM, (Andreas J. Koenig) via RT wrote: Show quoted text
> > <URL: http://rt.cpan.org/Ticket/Display.html?id=33419 > >
>>>>>> On Tue, 19 Feb 2008 18:56:30 -0500, "Michael G Schwern via RT" <bug-CPAN@rt.cpan.org
>>>>>> > said:
>
>> 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.
> > Beware to filter duplicates *manually*. You do not want to send > reports to authors who have already an open ticket on the issue. > > -- > andreas >
-- Stuart R. Jefferys I have 3.14 personalities, making me a well rounded individual.
Feb 21 22:34:14 2008, srj@unc.edu wrote: Stuart, latest Getargs::Long no longer uses auto_install. Show quoted text
> Ok. I'll see what time I can fit in. Is there a better forum to post > questions I might have to?
http://perlmonks.org, http://stackoverflow.com Or in bug tracker for failing module. -- Alexandr Ciornii, http://chorny.net