Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts
On Wed, 11 Jan 2017 14:59:06 -0500 Sam Hartman <hartmans@debian.org> wrote:
> I'll note that the practice of hard-coding paths is fairly common.
>
>
> One common cause for this is programs that don't want to rely on PATH
> for calling exec. Systemd is a particularly interesting example.
> ExecStart and related arguments in systemd units are required to include
> full paths.
>
> I am very uncomfortable with the idea of setting policy here. I find I
> tend to agree with Daniel's position a bit more than Ian's.
> In particular, I definitely think that for closely-related versions of
> software, making sure the same versions are used is helpful.
> I've hurt myself more by having parts of something built in /usr/local
> than I have not being able to override things for debugging.
> However, I
> think that both parties have valid points.
> So, I'd be much more comfortable if we wanted to help make people more
> aware of the tradeoffs than I would setting policy.
I've likewise run into far too many debugging and triage adventures
involving a program not running what it thought it was running, or for
interpreted languages, picking up a random local version of a module.
(At this point, when helping debug something on someone else's system, I
check early on for issues related to loading local copies of things
fairly early in the process.) Today's clever hack becomes tomorrow's
technical debt. And the more certainty a sysadmin has that they'd never
forget they had a locally installed override/hack, the deeper the
head-shaped indentations in the nearest desk or wall when it turns out
they do.
I don't want to argue that we should never invoke programs via $PATH, or
that we should never invoke programs via full pathnames. I can see
cases for both. Rather, I'd agree with Sam Hartman's comment above that
we should document both approaches and the tradeoffs between them. But
in terms of ecosystem fragility, it seems far worse to have the software
in Debian behave differently in this particular regard than the software
upstream, making it even more challenging to debug.
I find it surprising that this has ended up in front of the Technical
Committee before it has, for instance, ended up on debian-policy or
debian-devel for discussion. While Policy would not make a change that
would instantly declare a large number of packages de-jure buggy, those
two lists nonetheless seem like the right place to have this discussion
outside the context of any particular package.
Reply to: