Perl is a LsbInterpretedLanguage, so it will need to address similar issues.
What are the developer issues that might be helped by some sort of standard?
There is an extensive test suite for Perl 5. The only issue is that it can test perl only before it's installed; it's possible to adapt it to test an already installed perl, but nobody found the motivations or the tuits to do this until now. (this should not be be a huge work, though).
Update: Test suite has been packaged for runtime now.
Perl comes with an rather large standard library, and with a utility, perlivp(1) (Perl Installation Verification Procedure) to check that all modules and extensions are available.
Also, some modules that come with Perl will be built and installed only if the corresponding libraries are present on the system. For example, is libdb available for the DB_File module ? These prerequisites need to be defined.
Perl can be configured with or without support for threads, for large files, for 64-bit integers on 32-bit machines. Which of those options are to be specified in the LSB ? What would be the recommended values ? (Perhaps, for example, support for threads could be side-stepped, for stability issues, knowing that very few Perl applications actually use threads.)
P5P probably needs to liase with LSB to define the base configuration.
Upstream development mail list where some discussion has taken place.
(quoted from the mail list):
FWIW, Perl is supposed to have binary backward compatibility within a major version (e.g. 5.8.x), but not across major versions (e.g. 5.10 vs. 5.8). Forward compatilibity is not guaranteed at all (e.g. building a module with 5.8.8 to run with perl 5.8.7).
Perl does have syntax for version handling, which many modules already use:
require v5.6.1; # run time version check require 5.6.1; # ditto require 5.006_001; # ditto; preferred for backwards compatibility
A deprecation warning is introduced, and the feature is removed in the next major version. (that is, 5.[n+2].*)