[lsb-discuss] LSB perl modules, pass 2

[Stew Benedict]

Nicholas Clark wrote:
> 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?
>
>   
Absolutely. In this particular case (and it could just be my ignorance 
using this distribution), the package manager (yum) seems unable to 
locate and perl-Test-More or perl-Test-Builder for me to be able to 
install, and the core perl packages do not include the modules. Perhaps 
this is a distribution bug, and I can certainly open a bug in their 
bugzilla for feedback.
> 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.
>
>   
No disagreement with that, as long as behavior still follows the 
reference specification (perl's 5.8.8 docs currently).
We have hit situations where the perl test harness is very tightly 
coupled with the perl tarball it came from and can give what appear to 
be failures from differences the the text of the updated modules. We 
have an open bug to try and figure out how to make the tests version 
independent.


-- 
Stew Benedict
Linux Foundation