On Wednesday, 22 August 2018 13:26:30 AEST Ian Jackson wrote:
> In practice, replacing perl with a homebrewed actual perl is rare and
> in that case you want to put it in /usr/bin, because that's where all
> distributed perl scripts expect it to be.

(If you'd make it /usr/bin/perl anyway, isn't that really saying that there's 
no point in using env?)

> And IIRC with Python we have historically had the trouble that a
> Python compiled into /usr/local/bin has bizarre ideas about where to
> look for its modules, which means that this isn't a useful strategy
> anyway.

This is not a python-specific problem but since this assertion comes up here 
from time to time and you're keen to broaden this discussion, let's look at 
it.

For some interpreter /usr/local/bin/foo, there are two options for the module 
path:

* modules outside /usr/local are ignored; installing libbar-foo packages as 
dependencies no longer satisfies the functional requirement of providing 
module bar when running `foo`. One now gets to reimplement apt but with the 
added fun that the modules one installs aren't necessarily compatible with 
other foo-using distro packages that are installed. Good luck running 
anything.

* modules outside /usr/local are not ignored; distribution provided modules 
are not necessarily compatible with the interpreter for API or ABI reasons. 
When one runs code, it might be the distro provided module or a locally 
supplied module that is used. Some of them might even have been tested 
together and might even work. Good luck running anything.

Both options are pretty broken, sadly. (If this were easy, we wouldn't have 
significant disruption and lots of work to do every time new upstream releases 
of perl or python were uploaded, for instance.)

The problem might be more visible in python-land than perl-land but that is 
more to do with some combination of luck, popularity, development activity and 
perhaps admin experience. In the limit of a dead software ecosystem, one 
doesn't bother with newer interpreters/modules/libraries, and/or the chance of 
a backwards incompatible change is so tiny that one gets away with it.

Every place where /usr/local is earlier than /usr in a search path (PATH, 
LD_LIBRARY_PATH, @INC, sys.path etc) is a place where the local admin can 
accidentally break distribution-supplied tools while only doing things in the 
admin's /usr/local playground.

Flexibility sits on a scale between fragile and robust. The trick is working 
out how many footguns are appropriate to leave around our distribution.

cheers
Stuart

-- 
Stuart Prescott    http://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/         stu...@debian.org
GPG fingerprint    90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Reply via email to