[lsb-discuss] Perl in LSB 3.2 - RFC

[Stew Benedict]

On Fri, 8 Jun 2007, Tels wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Moin,
> 
> On Friday 08 June 2007 02:07:11 Paul Johnson wrote:
> > On Thu, Jun 07, 2007 at 07:25:48PM -0400, Stew Benedict wrote:
> > > On Fri, 8 Jun 2007, Paul Johnson wrote:
> > > > Perhaps I don't really understand the goals here.  What are you
> > > > looking for beyond "/usr/bin/perl should be at least 5.8.8 and work
> > > > according its tests and documentation"?
> > > >
> > > > I worry that getting into too much detail could prove problematic,
> > > > but too little detail seems to provide little benefit.
> > >
> > > Well, what ISVs really seem to want it is a detailed spec. I'm told
> > > Perl doesn't have one, and writing one isn't going to happen, from the
> > > Perl side. Short of the LSB writing one, this provides some middle
> > > ground of "perl should be present on the system and functional".
> >
> > I think that's a sensible and achievable goal.
> >
> > The functional part seems to be covered by passing tests and conforming
> > to standard documentation.  As for the rest, I would be tempted not to
> > allow anything to be removed from the standard distribution.  
> 
> I am very tempted to agree ;) The core set of modules is some sort of 
> baseline - if you find 5.8.8, it should better be come with everything that 
> was in the full release. 
> 

Is there a way we can enumerate what the core set of modules is? This 
would tell me what tests to include, and inform the ISV what perl 
functions are "safe" to use for an LSB application. Just specifying "the 
core set" seems a little vague.

> The only trick part are parts/extensions/modules that only work on one 
> platform. But the testsuite deals with that by skipping the tests.
> 

I've been filtering these out, after observing the skips in the test runs.
For LSB, it seems cleaner to not include a bunch of test that aren't 
expected to run anyway.

> > Even the crufty old perl4 libraries are there for backwards compatibility,
> > as James has noted.
> 
> I think it is good to sometimes break up with old stuff (*insert joke about 
> theoretical wife/girlfriend*). Do you really want systems out there where 
> some critical maintainance script is written in Perl 4? Ouch :)
> 
> > I suspect there might be more mileage in discussing versions, official
> > releases, patches, configuration options and default settings of
> > environment variables.  And I would tend to be rather conservative here.
> >

Can you suggest a test method for altered environment variables?

> > Perhaps something like the following?
> >
> >   version 5.8.x where x >= 8 (as suggested)
> 
> Allowing for 5.8.x is certainly good - as we wouldn't really want to be 
> everyone stuck on 5.8.8 when 5.8.9 comes out as these stable releases are 
> really binary-compatible and backwards-compatible as much as possible - 
> this is one thing Perl is really good at.
> 

OK, I've got the message here :), 5.8.x with x >= 8

> >   only official releases
> >   no patches
> 
> This wouldn't allow any vendor patches - which I almost think would be good.
> 
> But it also wouldn't allow a vendor pulling a dual-live module from CPAN and 
> updating it. So, if 5.8.x goes into a lapse (like 5.8.8 is now 
> quite "old" :-), you would still be stuck with whatever was delivered with 
> it - bugs and warts and all until 5.8.x+1 comes out.
> 

I don't think you'll get the distributions to buy in to this.  Patches are 
pretty typical. We also don't really have any way to know what went into 
the source build, aside from a test failing.

Likewise for the /usr/bin/lsb-perl suggestion.  LSB tries to document 
current practice. Afaik, no-one is shipping an lsb-perl, and I suspect 
we'd see considerable pushback from the distributions if we were to 
suggest they ship multiple versions of perl. I realize this could just be 
a symlink, but we'd still need to convince the distributions to provide 
it. 

> This brings me to another important point which I overlooked - what about 
> wrong tests? A test tests accidentily for buggy behaviour (happened f.i. 
> with BigInt a few times). If you only specifiy 5.8.x and a testsuite, then 
> a 5.8.9 with that bug fixed (and a different testsuite) would pass its own 
> testsuite (since it is corrected), but not the one from LSB 3.2. Hm.
> 

Yes, hitting the same issue on the Python side. Running a 2.4.4 test suite 
against 2.4.2 fails against specific bugs that were fixed since 2.4.2. 
Running the older test suite against the newer Python fairs better, but 
there's still a chance of failures. We see this in other areas of LSB too, 
as libraries change etc., at which point the distribution (or LSB 
engineers) may file a bug against the test, and we come to a decision as 
to whether the test is bad, or the implementation has changed in an 
incompatible fashion. Then we either fix the test, or file a bug upstream.

-- 
Stew Benedict
The Linux Foundation