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

Robin Bryce robinbryce at gmail.com
Fri Dec 1 12🔞44 CET 2006

Fair enough.

Robin

On 30/11/06, "Martin v. Löwis" <martin at v.loewis.de> wrote:

Robin Bryce schrieb: > Yes, especially with the regard to the level you pitch for LSB. I > would go as far as to say that if this "contract in spirit" is broken > by vendor repackaging they should: > * Call the binaries something else because it is NOT python any more. > * Setup the installation layout so that it does NOT conflict or > overlap with the standard layout. > * Call the whole package something else.

I think that would be counter-productive. If applied in a strict sense, you couldn't call it Python anymore if it isn't in /usr/local. I see no point to that. It shouldn't be called Python anymore if it doesn't implement the Python language specification. No vendor is modifying it in such a way that print "Hello" stops working. > Is it a bad idea to suggest that: Python grows a vendorvariant > attribute somewhere in the standard lib; That its content is > completely dictated by a new ./configure argument which is the empty > string by default; And, request that it is left empty by re-packagers > if the installation is 'reasonably standard' ? I'm not sure in what applications that would be useful. > I would strongly prefer not write code that is conditional on such > an attribute. However if there was a clear way for a vendor to > communicate "This is not a standard python runtime" to the python run > time, early failure (in the application) with informative error > messages becomes much more viable. Again: none of the vendors modifies Python in a way that what you get is "not a standard Python runtime". They all are "standard Python runtimes". Regards, Martin

More information about the Python-Dev mailing list