Bug#906901: debian-policy: Perl script shebang requirement is disturbing and inconsistent with rest of policy
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/ stuart@nanonanonano.net
Debian Developer http://www.debian.org/ stuart@debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Reply to: