[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