[lsb-discuss] Perl, Python in LSB 3.2

Robert Schweikert robert.schweikert at mathworks.com
Mon Jun 18 19:13:00 PDT 2007


Finally getting to weigh in on this one, sorry for the delay.

I believe whether or not an ISV will ship Perl or Python will depend on 
the level of integration with the ISVs application. If either language 
is used for utility purposes as an external resource it should be 
relatively easy for an ISV to stop shipping either interpreter provided 
the LSB specifies a sufficient version and a sufficient number of 
modules (more on this later). If the interpreter is tightly integrated 
and part of the application itself it will be much more difficult for an 
ISV to not ship the interpreter.

For an ISV not to ship the interpreter the LSB will have to specify the 
version of the interpreter and the modules which are considered part of 
the installation. In addition the behavior of the functions provided by 
the modules will need to be documented (this will be easy for Python).

The problem with Python is the magic cookie. While the ISV can 
re-compile the Python code with the appropriate interpreter the LSB 
deprecation policy will work against the frequent changes of the magic 
cookie in Python. Somehow newer versions of the interpreter will need to 
behave like older versions and will need to execute code from older 
magic cookies.

The LSB can still help ISVs who need to ship the interpreter due to 
integration purposes by assisting the community to make the interpreter 
itself LSB compliant.

Robert

Stew Benedict wrote:
> Just to keep the discussion going as we sort of hit a time constraint at 
> the F2F.
> 
> I think I heard a pretty strong "no" to just specifying /usr/bin/perl, 
> /usr/bin/python as being a usable solution.
> 
> I also think I heard the message that the large ISVs are likely to still 
> ship their own Python, Perl, Java, etc.,as the stakes are too high to 
> depend on behavior of the distribution copy.
> 
> So, to reiterate Mats' earlier question, is what we're trying to do with 
> Perl (Python is likely to be similar), going to meet the needs of those 
> ISVs that feel LSB needs to include these languages?
> 
> http://www.linux-foundation.org/~stewb/lsb-perl/perlspec/
> 
> That is:
> 
> Define interpreter binary location, minimum version
> Define a list of modules expected to be present, with a reference to the 
> upstream language specification. At this point, "the list" for Perl, is 
> only modules coming from the base perl tarball, nothing from CPAN, etc.
> 
> It looks like we have a promising resource in the Perl Foundation, with 
> Allison, but before I ask them to do the work to write a language spec 
> with the proper specification language, I want to make sure we're actually 
> going to be solving the perceived problem in not having these languages as 
> part of LSB.
> 
> I'd also like to make sure we're on track before I burn too many cycles 
> patching a few hundred more perl tests to run against the installed perl.
> 

-- 
Robert Schweikert                          MAY THE SOURCE BE WITH YOU
(robert.schweikert at mathworks.com)                        LINUX
The MathWorks Inc.
Phone: 508-647-2042




More information about the lsb-discuss mailing list