[lsb-discuss] LSB perl modules, pass 2

Stew Benedict stewb at linux-foundation.org
Thu Jan 22 05:10:47 PST 2009


Nicholas Clark wrote:
> On Thu, Jan 22, 2009 at 10:49:48AM +0100, demerphq wrote:
>   
>> 2009/1/21 Stew Benedict <stewb at linux-foundation.org>:
>>     
>>> A year+ back, when we were adding Perl to LSB-3.2, we published a list of
>>> proposed modules, hoping for expert feedback as to whether this list made
>>> sense, from a standards sense, as a stable set of modules, with stable APIs,
>>> that could be expected to be present on a typical Linux distribution. Since
>>>       
>
> What exactly is the intent to certify? That a Linux distribution has a package,
> or set of packages, installed, that constitute a standard, stable Perl?
>
>   
>>> Test::Harness::Straps is now deprecated. This email is another attempt to go
>>> over where we've been with the perl modules, what we've removed, what may be
>>> removed soon, and another look at what remains so that those in the know can
>>> tell us what we should *not* be including. This will avoid us having to keep
>>> going back and say "oops" and pulling things out, short-circuiting our own
>>> deprecation policy.
>>>       
>
> Yes, I can see how this happened. The assumption (pretty much forever) is that
> modules don't get removed from core, so it certainly didn't occur to me that
> modules would get removed. So sorry about the mix up over
> Test::Harness::Straps
>
>
>   
>>> Modules under consideration to remove now (ref:
>>> http://bugs.linuxbase.org/show_bug.cgi?id=2461)
>>>       
>> Removing these modules in this way would be a very very very bad thing.
>>
>>     
>>> Test::Builder
>>> Test::Builder::Module
>>> Test::Builder::Tester
>>> Test::Builder::Tester::Color
>>>       
>> Keep these
>>
>>     
>>> Test::Harness
>>>       
>> This definitely MUST stay.
>>
>>     
>>> Test::Harness::Assert
>>> Test::Harness::Iterator
>>> Test::Harness::Point
>>> Test::Harness::Straps
>>>       
>> Arguable these should never have been included in the first place.
>> They were semi-documented internal interfaces that were always
>> documented as experimental.
>>     
>
> but no-one spotted this. I think partly because we didn't understand how the
> LSB is supposed to work, and partly because the plan for Test::Harness in
> the core hadn't actually been worked out back then.
>
>   
>>> Test::More
>>>       
>> This definitely MUST stay.
>>
>> If you remove these modules then your definition of what a standard
>> perl bundle contains will be so far from ours that it will negate the
>> usefulness of it at all.
>>
>> The problem here is that you kinda violated an encapsulation barrier
>> when you set this up at first. This is our fault in that we shouldnt
>> have let Straps live for so long as an experimental module. Now that
>> we have replaced it however it should not be seen as a reason to
>> perceive Test::Harness as unstable.
>>
>> In fact Test::Harness is stable, it merely has a new internal implementation.
>>
>> There are many modules which it is perfectly reasonable to discuss
>> eliminating. However
>>
>> Test::More
>> Test::Harness
>> Test::Builder (and friends)
>>
>> Arent among them at all. Not even close. I personally would view these
>> modules as in practice being only moderately less important than the
>> perl executable itself.
>>     
>
>   
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.
> Yes, I agree. I'm confident that all Perl core developers would consider
> anything that claimed to be "Perl" which didn't ship Test::More, Test::Simple,
> Test::Harness and Test::Builder as bowdlerised such that it had no credible
> claim to the name.
>
> But it comes back to my previous question - what does the LSB need to certify?
> That a single package provides "Perl", or that a stated set of packages
> provides it?
>
>
>   
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.

-- 
Stew Benedict
Linux Foundation




More information about the lsb-discuss mailing list