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: Eric S. Raymond
Subject: Re: [gpsd-dev] python2 and absolute paths
Date: Tue, 21 Jul 2015 06:38:03 -0400
User-agent: Mutt/1.5.23 (2014-03-12)

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.

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.

If you're Larry or Guido, you telegraph that you're going to break
forward compatibility by *bumping the major version*.  Everyone expects
this.  And if you're reasonable distribution engineer, you do your
part in the dance by *creating explicit links for each major version^.

For example, I just checked how "perl", "perl5" and "per6" work on my
Ubuntu 14 system and found exactly what I expected; "perl5" calls Perl 5,
"perl" calls Perl 5, and if you install Perl, "perl6" calls Perl 6.  As
expected, "perl" calls Perl 5 but I would not be surprised if at some
future date it began to call Perl 6.

I expect any scripting language to be treated similarly because it's
what makes *sense* - it's Schelling-point behavior - on the one assumption
that major bumps are used to signal forward-incompatible changes. I would
have been astonished if Perl had been packaged differently from Python in
this regard.

In light of this convention, expecting people who ship Perl or Python
scripts to do bang path surgery is absurd.  You expect them to feed
the major-version-specific name (be it perl5, python2, or fubar23) to
#!/usr/bin/env, and done.

If *BSD, or anything else, doesn't support this convention, it's not
GPSD that has a bug needing fixing.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

Attachment: signature.asc
Description: Digital signature


reply via email to

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