[Python-Dev] Python and the Linux Standard Base (LSB)

[Phillip J. Eby]

At 11:09 AM 11/22/2006 -0500, Ian Murdock wrote:
>The first question we have to answer is: What does it mean to "add
>Python to the LSB"? Is it enough to say that Python is present
>at a certain version and above, or do we need to do more than that
>(e.g., many distros ship numerous Python add-ons which apps
>may or may not rely on--do we need to specific some of these too)?

Just a suggestion, but one issue that I think needs addressing is the FHS 
language that leads some Linux distros to believe that they should change 
Python's normal installation layout (sometimes in bizarre ways) or that 
they should remove and separately package different portions of the 
standard library.  Other vendors apparently also patch Python in various 
ways to support their FHS-based theories of how Python should install 
files.  These changes are detrimental to compatibility.

Another issue is specifying dependencies.  The existence of the Cheeseshop 
as a central registry of Python project names has not been taken into 
account in vendor packaging practices, for example.  (Python 2.5 also 
introduced the ability to install metadata alongside installed Python 
packages, supporting runtime checking for package presence and versions.)

I don't know how closely these issues tie into what the LSB is tying to do, 
as I've only observed these issues in the breach, where certain 
distribution policies require e.g. that project names be replaced with 
internal package names, demand separation of package data files from their 
packages, or other procrustean chopping that makes mincemeat of any attempt 
at multi-distribution compatibility for an application or multi-dependency 
library.  Some clarification at the LSB level of what is actually 
considered standard for Python might perhaps be helpful in motivating 
updates to some of these policies.