Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts
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 <ijackson@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.
Reply to: