On Wed, 11 Jan 2017 14:59:06 -0500 Sam Hartman <hartm...@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.