On 07 April 2005 23:02 Ken Williams wrote: > On Apr 6, 2005, at 7:13 AM, Robert Rothenberg wrote: > >> Is there a way tests to determine that a module cannot be installed >> on a platform so that CPANPLUS or CPAN::YACSmoke can issue an "NA" >> (Not Applicable) report? >> >> CPANPLUS relies on module names (e.g. "Solaris::" or "Win32::") but >> that is not always appropriate in cases where a module runs on many >> platforms except some that do not have the capability. > > In those cases, who's to say that that platform won't get such > capabilities in the future? If the module author has to list the > platforms on which their module won't run, it'll get out of date, and > the list will likely be incomplete to start out with.
This is something that Robert and I have discussed. It is rather difficult to decide how to approach this. However, thinking about what *might* happen in the future for a future platform, is not relavent to what we were thinking. There real problems now, such as alarm(), symlinks and fork() on Win32, that create problems when distributions use them. There are some distributions that only require them for testing, which to my mind currently means bogus FAIL reports are generated. If the distribution author is able to indicate which platforms they are willing to support, then it could mean a NA report is generated, until such a time as the author is willing to support that platform. The reasoning behind all this, is that several authors have raised the subject of getting FAIL reports for platforms they are not willing or unable to support. We were trying to think of an adequate way of avoiding sending them reports which they are not interested in currently. I know it could easily be a matter of pressing the delete key, but seeing as it has been a wishlist item that keeps getting mentioned, Robert and I figured it might be something we can address. >> There's also a separate issue of whether "NA" reports should be >> issued if a library is missing. (Usually these come out as >> failures.) > > People looking at failure reports should be able to tell whether the > failure occurred because of a missing prerequisite (of which libraries > are one variety) or because of runtime building/testing > problems. The > correct way to solve this would be to have a mechanism for declaring > system library dependencies, then check before smoke-testing whether > those dependencies are satisfied. This is also something I've been thinking about for about a year. My only conclusion is that an addition test grade be created, which implies that the distribution could not be completed, due to dependancies outside the realm of the distribution or the install mechanism. My patch to CPANPLUS was to not produce a report, but I do think it could be something users may wish to know about. > Unfortunately that's a large problem space, and it has eluded attempts > at cross-platform solutions so far. It would be really nice > if it were > solved, though. You're right it is a large problem space. There have been a few attempts to figure it out, but as different platforms have different methods of recording library information, it isn't going to be a quick fix. On 07 April 2005 23:12 Michael G Schwern wrote: > On Thu, Apr 07, 2005 at 05:01:34PM -0500, Ken Williams wrote: >>> Is there a way tests to determine that a module cannot be installed >>> on a platform so that CPANPLUS or CPAN::YACSmoke can issue an "NA" >>> (Not Applicable) report? > > AFAIK NA reports are issued when a Makefile.PL dies due to a "require > 5.00X" failing. That's the only way I've seen anyway. Not true. The current CPANPLUS now will produce a NA report if the perl version is lower than that specified by the distribution/module. This is checked for as part of the prepare, build and test stages, not just the prepare stage. Previously, the only time a NA report was produced was when one of the 3 stages failed, and the top level namespace matched a platform name that wasn't the current platform. This was why a while ago there were some NA reports for distributions in the 'MAC::' namespace. There was a case insensitive test that thought it was in the 'Mac::' namespace. Hope that clarifies a few points. Cheers, Barbie. -- Barbie (@missbarbell.co.uk) | Birmingham Perl Mongers user group | http://birmingham.pm.org/ --------------------------------------------------- This mail sent through http://www.easynetdial.co.uk
