Package: tech-ctte Control: block 850657 by -1 Policy 6.1 says | Programs called from maintainer scripts should not normally have a | path prepended to them.
Ie, programs that are on PATH should be found via the PATH rather than by hardcoding /usr/bin/foo or whatever. In general, I think we normally, at least in software written specifically for Debian, apply this not just to maintainer scripts but to all program execution. However, this is not always uncontroversial with some upstreams. This causes a particular problem when the upstream is also heavily involved with the Debian maintenance. I would like the TC to: * Declare that Debian policy should be clarified to say that programs in Debian (not just maintainer scripts) should not hardcode the location of the binaries in /{usr/,}{bin,sbin} they execute. * Say that this applies even when the program needs to find pieces of the same (or closely related) package. * Say that where technically feasible, this should usually be done for other kinds of search paths (LD_LIBRARY_PATH, PYTHONPATH, PERLLIB, etc.), too. * Provide an informal opinion that this policy ought to apply to gpg-agent as requested in #850657. I don't know if it is necessary to rehearse the arguments about this issue for the TC, but I will try to do so briefly. The argument in favour of finding programs (and libraries) on the PATH: This allows substitution and wrapping of programs (by adding a directory to PATH containing a stunt version of the program, or by adding a wrapper or replacement to /usr/local or ~/bin). This can be useful in a wide variety of situations. It is a well-known debugging technique. It can be used by individual users, to modify the behaviour of their system. It can be profitably used by things like test suites and audit tools. It can be used by depending software to work around bugs. Most of these uses can be satisfied in some other way, but the other ways have downsides. For example, moving the actual binary aside is a possibility (and supported by things like dpkg-divert); but it affects the whole system, so requires administrator privilege; it is unsuitable on a multiuser machine or for test suites; and if done ad-hoc it is too easy to forget to put back and leave the system in a weird state. Explicit configuration or command line options to change which subcommands are used are a good thing, but: they are usually fiddly and certainly not always provided; this can often involve complicated nesting (eg run `foo' with --bar-program pointing to a stunt `bar' script which passes --wombat-program pointing to your stunt `wombat' script); and lack of such an option at any level stymies this approach. I will quote the counterarguments from Daniel Kahn Gillmor, as they are fairly typical of the responses from upstreams: In this bug report, you're asking a tightly-coupled suite of tools to invoke each other via the PATH, which offers another avenue of potential breakage; upstream regularly receives reports from people who *don't even know what version of gpg their system is running* because of multiple copies of the thing having been installed in various places on their system (either deliberately or incidentally, but in either case forgotten about by the local sysadmin). It's entirely reasonable for a tightly-coupled suite to want to invoke its own tools in this situation. we have enough to debug in GnuPG as it is :/ Perhaps this is indeed a problem for some upstreams. But I have two responses to this which I think are each sufficient to rebut it: Firstly, we are talking about this in the context of Debian. In Debian we have `reportbug', which the majority of people use to file bug reports. It would be simple for reportbug to report on these kind of anomalous situations and mention them in the bug report. It could, for example, check to see if there is overlap between the package being reported (and its dependencies), and /usr/local. I don't know if it does already, but if it doesn't and someone feels the information is valuable, then I'm sure the patches to reportbug would be welcome. Secondly, I think the possibility that users may do things upstream consider undesirable, and even cause lossage, is precisely software freedom. The thrust of the upstream argument here is that users must be prevented from messing with their software in certain ways because it makes those users' bug reports too hard to deal with. I think this argument is utterly wrong in principle. It is contrary to the whole point of Debian. Thanks for your attention. Ian. PS: Please give the MIPS binutils bug priority. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.