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
