Front page | perl.perl5.porters |
Postings from January 2009
Re: LSB perl modules, pass 2
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
January 22, 2009 05:58
Subject:
Re: LSB perl modules, pass 2
Message ID:
20090122135835.GC95022@plum.flirble.org
On Thu, Jan 22, 2009 at 08:10:47AM -0500, Stew Benedict wrote:
> OK. Test::Harness ended up in the list along with it's sub-modules. If
> Test::Harness hasn't changed it could stay. Test::More, which seems to
> require Test::Builder is on the list because I'm not finding it in the
> distribution in question, and subsequently 200-some tests in the perl
> test suite fail due to lack of it.
Test::More (and Test::Simple) are implemented on top of Test::Builder
Most of the core tests in lib/ and ext/ are written using Test::More, and
are going to fail if it's not present.
Additionally, the concept of testing is deeply ingrained in Perl. perl 1.000
shipped with regression tests in t/*/*.t, which is where they still are today.
The encouragement of testing is such that the Perl 6 standard will include
testing built in. So I'd not consider this distribution (as described) as
shipping a standard Perl.
> LSB doesn't attempt to dictate how the required Perl is packaged, it can
> be one or many packages. But most distributions handle the situation
> with a "lsb" metapackage to pull in the required bits. Perl is too new
> yet (in LSB) for the distributions to have noticed and included in their
> metapackages, but it is presumed it will happen at some point.
Ah right. That's good.
So if the above distribution has packaged Test::More and Test::Builder
separately, then it meets the standard once it rejigs its metadata or
metapackages such that the perl testing package is also installed?
As Yves said, it's actually beneficial to flexibility to package up the
various modules that the core aggregates from CPAN ("dual life modules")
as distinct packages, as it allows a distribution to track changes from them
without needing to constantly integrate them with, and repeatedly ship, a
full perl package. The potential downside of this, however, is a
combinatorial explosion of combinations of packages installed, which I
infer means a testing headache.
Certainly I see no reason for a distribution to refrain from doing either.
I was a bit surprised when someone pointed me at a ticket in some
distribution's bug tracker (forget which), where the user had reported that
their perl 5.8.8 package had version 1.06 (or so) of the threads module, but
the current version on CPAN was 1.70 (or so). The ticket had been closed
with the simple (and accurate) comment that the version of threads in
the maint-5.8 branch of upstream was still 1.06. [And a comment that they
would ask why I hadn't updated it. I never remember that distribution'
maintainer having the time to mail me to ask this. Everyone is overworked]
Had I been asked, I would have answered "I'm going to update it. I just
haven't done it yet. The CPAN version is canonical. Please do update yours"
Anyway, maint-5.8 isn't my problem now. :-)
Nicholas Clark
Thread Previous
|
Thread Next