Perl in LSB 3.2 - RFC

I've done a little more work on the tests, adding more tests
from 
lib/{a..z}*.t, as well as hacking in some basic TET
support.

http://www.linux-foundation.org/~stewb/lsb-perl/MANIFEST


(I'd still be interested in that TAP<->TET converter)

http://www
.linux-foundation.org/en/LsbPerl

Page has some summary update from the list discussions, and
various test 
results from several distros, which reveal I've still got a
couple of 
packaging issues, but overall not too bad.

So,

Does this test subset seem like a reasonable one?

Perl 5.8.8 seems pretty common across the distributions of
interest. Short 
of writing a formal language spec for perl, is there some
middle ground 
we can agree on for a "relaxed" specification for
LSB, that the perl 
community is willing to accept and support? (ISVs seem to
really want a 
formal language spec).

Something like:

Version: 5.8.8

Interpreter binary (or symlink) exists at /usr/bin/perl

The following functions/operators from core,libs,ext shall
be supported 
(driven by what's included in the test suite MANIFEST,
formatted appropriately).

ISV reference for usage would point to http://perldoc.perl
.org/perl.html 
(is this a static document, or is there a static location
for 5.8.8 
specifically?)

Then, at some point in the future, we'd have to look at
uplifting the 
perl version specified in the LSB spec, and deal with any
deprecation 
issues.

Does perl have any sort of policy for deprecating features?
Supporting 
with a warning for some period?  
 
Regards,
-- 
Stew Benedict
The Linux Foundation

On 30 May 2007, at 22:02, Stew Benedict wrote:

>
> I've done a little more work on the tests, adding more
tests from
> lib/{a..z}*.t, as well as hacking in some basic TET
support.
>
> http://www.linux-foundation.org/~stewb/lsb-perl/MANIFEST

>
> (I'd still be interested in that TAP<->TET
converter)

On it's way - got sidetracked by the real world 

-- 
Andy Armstrong, hexten.net

On 30/05/07, Stew Benedict <stewblinux-foundation.org>
wrote:
>
> I've done a little more work on the tests, adding more
tests from
> lib/{a..z}*.t, as well as hacking in some basic TET
support.
>
> http://www.linux-foundation.org/~stewb/lsb-perl/MANIFEST

>
> (I'd still be interested in that TAP<->TET
converter)
>
> http://www
.linux-foundation.org/en/LsbPerl
>
> Page has some summary update from the list discussions,
and various test
> results from several distros, which reveal I've still
got a couple of
> packaging issues, but overall not too bad.
>
> So,
>
> Does this test subset seem like a reasonable one?

At a first glance yes.
About the wiki page: "Perl Configuration" : my
advice would be to
configure only with large files. threads are more specific,
and 64 bit
integers on 32 bit machines aren't used much I think.

> Perl 5.8.8 seems pretty common across the distributions
of interest. Short
> of writing a formal language spec for perl, is there
some middle ground
> we can agree on for a "relaxed" specification
for LSB, that the perl
> community is willing to accept and support? (ISVs seem
to really want a
> formal language spec).
>
> Something like:
>
> Version: 5.8.8
>
> Interpreter binary (or symlink) exists at
/usr/bin/perl

or hardlink (that's a common case) usually to
/usr/bin/perl5.8.8

> The following functions/operators from core,libs,ext
shall be supported
> (driven by what's included in the test suite MANIFEST,
formatted appropriately).
>
> ISV reference for usage would point to http://perldoc.perl
.org/perl.html
> (is this a static document, or is there a static
location for 5.8.8
> specifically?)

I think you can use:
http://search.cpan.org/~nwclark/perl-5.8.8/pod/perl.pod

> Then, at some point in the future, we'd have to look at
uplifting the
> perl version specified in the LSB spec, and deal with
any deprecation
> issues.
>
> Does perl have any sort of policy for deprecating
features? Supporting
> with a warning for some period?

Yes: a deprecation warning is introduced, and the feature is
removed
in the next major version. (that is, 5.[n+2].*)

On Thu, 31 May 2007 10:14:06 +0200, "Rafael
Garcia-Suarez"
<rgarciasuarezgmail.com> wrote:

> On 30/05/07, Stew Benedict <stewblinux-foundation.org> wrote:
> >
> > I've done a little more work on the tests, adding
more tests from
> > lib/{a..z}*.t, as well as hacking in some basic
TET support.
> >
> > http://www.linux-foundation.org/~stewb/lsb-perl/MANIFEST

> >
> > (I'd still be interested in that TAP<->TET
converter)
> >
> > http://www
.linux-foundation.org/en/LsbPerl
> >
> > Page has some summary update from the list
discussions, and various test
> > results from several distros, which reveal I've
still got a couple of
> > packaging issues, but overall not too bad.
> >
> > So,
> >
> > Does this test subset seem like a reasonable one?
> 
> At a first glance yes.
> About the wiki page: "Perl Configuration" :
my advice would be to
> configure only with large files. threads are more
specific, and 64 bit
> integers on 32 bit machines aren't used much I think.

Large files is default when available.
I use use64bitint wherever and whenever possible. Also on
32bit machines,
like Linux. This is not possible on HP-UX. There it is
either 32bitall or
64bitall. I myself still discourage threaded builds as
default distribution.
Maybe more important choice for distributors is if
-DDEBUGGING is on or off,
as that influences the available commandline options
(-D...)

> > Perl 5.8.8 seems pretty common across the
distributions of interest. Short
> > of writing a formal language spec for perl, is
there some middle ground
> > we can agree on for a "relaxed"
specification for LSB, that the perl
> > community is willing to accept and support? (ISVs
seem to really want a
> > formal language spec).
> >
> > Something like:
> >
> > Version: 5.8.8
> >
> > Interpreter binary (or symlink) exists at
/usr/bin/perl
> 
> or hardlink (that's a common case) usually to
/usr/bin/perl5.8.8
> 
> > The following functions/operators from
core,libs,ext shall be supported
> > (driven by what's included in the test suite
MANIFEST, formatted appropriately).
> >
> > ISV reference for usage would point to http://perldoc.perl
.org/perl.html
> > (is this a static document, or is there a static
location for 5.8.8
> > specifically?)
> 
> I think you can use:
> http://search.cpan.org/~nwclark/perl-5.8.8/pod/perl.pod
> 
> > Then, at some point in the future, we'd have to
look at uplifting the
> > perl version specified in the LSB spec, and deal
with any deprecation
> > issues.
> >
> > Does perl have any sort of policy for deprecating
features? Supporting
> > with a warning for some period?
> 
> Yes: a deprecation warning is introduced, and the
feature is removed
> in the next major version. (that is, 5.[n+2].*)
> 


-- 
H.Merijn Brand         Amsterdam Perl Mongers (http://amsterdam.pm.org/
)
using & porting perl 5.6.2, 5.8.x, 5.9.x   on HP-UX
10.20, 11.00, 11.11,
& 11.23, SuSE 10.0 & 10.2, AIX 4.3 & 5.2, and
Cygwin. http://qa.perl.org
http://mirrors.de
velooper.com/hpux/            http://www.test-smoke.org
                        http
://www.goldmark.org/jeff/stupid-disclaimers/

On Thu, 31 May 2007, H.Merijn Brand wrote:

> On Thu, 31 May 2007 10:14:06 +0200, "Rafael
Garcia-Suarez"
> <rgarciasuarezgmail.com> wrote:
> > About the wiki page: "Perl
Configuration" : my advice would be to
> > configure only with large files. threads are more
specific, and 64 bit
> 
> > integers on 32 bit machines aren't used much I
think.
> 
> Large files is default when available.
> I use use64bitint wherever and whenever possible. Also
on 32bit machines,
> like Linux. This is not possible on HP-UX. There it is
either 32bitall or
> 64bitall. I myself still discourage threaded builds as
default distribution.
> Maybe more important choice for distributors is if
-DDEBUGGING is on or off,
> as that influences the available commandline options
(-D...)
> 

Thanks,

I suspect we might stay away from trying to specify how the
distributions 
should configure, as we'd see considerable push-back in
trying to certify 
already published distributions. From what I've seen of the
test runs, the 
tests skip if ithreads or 64bitint are not enabled, which is
probably 
acceptable.

-- 
Stew Benedict
The Linux Foundation

On Thu, 31 May 2007, Rafael Garcia-Suarez wrote:

> On 30/05/07, Stew Benedict <stewblinux-foundation.org> wrote:
> >
> > Interpreter binary (or symlink) exists at
/usr/bin/perl
> 
> or hardlink (that's a common case) usually to
/usr/bin/perl5.8.8
> 

Right, I think the variations of this configuration are
what's catching me 
on the magic test.

> > The following functions/operators from
core,libs,ext shall be supported
> > (driven by what's included in the test suite
MANIFEST, formatted appropriately).
> >
> > ISV reference for usage would point to http://perldoc.perl
.org/perl.html
> > (is this a static document, or is there a static
location for 5.8.8
> > specifically?)
> 
> I think you can use:
> http://search.cpan.org/~nwclark/perl-5.8.8/pod/perl.pod
> 

I'll change the wiki link to this.

> > Then, at some point in the future, we'd have to
look at uplifting the
> > perl version specified in the LSB spec, and deal
with any deprecation
> > issues.
> >
> > Does perl have any sort of policy for deprecating
features? Supporting
> > with a warning for some period?
> 
> Yes: a deprecation warning is introduced, and the
feature is removed
> in the next major version. (that is, 5.[n+2].*)
> 

Good, this is great information.

-- 
Stew Benedict
The Linux Foundation