Front page | perl.perl5.porters |
Postings from July 2008
On Tue, 15 Jul 2008, Reini Urban wrote:
> 2008/7/14 Andy Dougherty <doughera@lafayette.edu>:
> >> I think the problem is that this perl has been built to look in a
> >> directory with old incompatible CPAN packages.
> >
> > I should add that I agree that you can make a good case for ensuring that
> > the perl you are testing isn't affected by things outside the core package
> > supplied with perl itself.
> >
> > However, in this case, allowing the outside to "accidentally pollute" the
> > testing environment has led to a useful outcome: The user is now aware
> > that there is a conflict between the existing installed CPAN modules and
> > the newly-built perl. This conflict may not appear to be a core issue,
> > but I think, on balance, the end user is well-served in this case by
> > discovering this issue during testing and before installation.
> "Users" are also smoke-testers.
> They will report false smoke reports with potential problems with
> external dependencies
> which can easily circumvented. This holds for this perldb5.t testcase,
> my latest B-Debug patch and also for upcoming Module-Build and
> ExtUtils::CBuilder patches with similar runtest problems.
> All these problems are with runperl() which picks up the default @INC
> pointing to old XS modules.
Fair enough. I agree that ignoring those paths is, in general, the right
thing for a test suite to do.
However, I still think there's a different bug lurking here: Why has this
perl been built to look in a directory with old incompatible CPAN
packages? Is it because it's a development version and we haven't updated
PERL_API_VERSION and PERL_API_SUBVERSION in patchlevel.h?
--
Andy Dougherty doughera@lafayette.edu
Thread Previous
|
Thread Next