gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] python2 and absolute paths


From: Greg Troxel
Subject: Re: [gpsd-dev] python2 and absolute paths
Date: Tue, 21 Jul 2015 07:22:59 -0400
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.5 (berkeley-unix)

"Eric S. Raymond" <address@hidden> writes:

> Greg Troxel <address@hidden>:
>> 
>> Please explain how it is sane for a program to build against one python
>> version, including building modules that link a path to a specific
>> library, and then just magically change to a different version with a
>> different ABI.  Have you actually tested this?  It obviously can't work
>> in the general case.  What I mean is to build gpsd with python2.6
>> installed and python2.7 not installed, with python2 pointing to 2.6.
>> Then with the package management system, add 2.7 and remove 2.6, telling
>> it to point python2 at 2.7.  Then run gpsd from the installed binaries,
>> including things that use the python stuff in PYSITELIB.  Are you saying
>> that this really works?
>
> Yes, actually I'm pretty sure it does. GPSD is written to 2.6; if there's
> an unknown 2.7 dependency in GPSD code no one has tripped over it yet and
> I would treat such a thing as a bug to be fixed.  And note that the version
> number of Python is not mentioned anywhere in our build recipe, because
> it's never had to be.

But I'm not talking about API compat.  I'm talking about ABI
compatibility of what's been built.  gpsd bakes in paths to the python
version, in library linking, and where files get put.  So it basically
can't work after changing out the interpreter from 2.6 to 2.7 without a
rebuild.

> Nor is this unusual.  Picking two consecutive versions at random, nobody would
> expect scripts written to Perl 4.3 to fail on Perl 4.4.  More generally, 
> nobody
> expects a minor-version bump of a language interpreter to produce forward
> incompatibility and if it does that would be regarded serious failure in
> release engineering and cause a public outcry.

Your expectations are reasonable, but that's not how python has been.
If it were, then packaging systems would not have had python 2.4 through
2.7 in parallel.

Even with perl, updating pkgsrc to 5.22 resulted in a bunch of
failures.   They were all nits that were easy to fix, the same kind of
thing that happens with C code with newer compiler versions.    The
point is that it's easier to fix them all than to maintain two versions
in parallel, unlike what happened with python.

Why there is no outcry is a good question.

Attachment: pgpgRuJ0fNf6b.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]