Home Original page

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

Robin Bryce robinbryce at gmail.com
Fri Dec 1 12:18: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 vendor_variant
> > 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