[Pkg-systemd-maintainers] Bug#732981: Bug#732981: Bug#732981: ExecStart et al should be capable of honouring PATH

[Tollef Fog Heen]

]] Ian Jackson 

> > I personally find this a bit thin on rationale. I.e. the policy only
> > states that one can expect certain binaries and that one should use
> > $PATH, but it doesn’t explain _why_.
> > 
> > Maybe you can clarify?
> 
> The purpose is that the administrator can override existing programs
> by putting them earlier on the PATH, perhaps in /usr/local or perhaps
> elsewhere.

You could make the case for lots of other bits:

- hashbangs should then clearly always use /usr/bin/env, since you might
want to use another interpreter than the one currently specified.
- rpaths must always include the relevant directory in /usr/local/lib,
since you might want to override the private libraries for a package.
- binaries must always check /usr/local for bits of packages, not jusr
/usr or /.

On my system, about 20% of binaries in /usr/bin reference something in
/usr/lib.  I'm sure some of them also check /usr/local, but from casual
inspection most don't.

> Would you accept a patch to fix this problem in Debian's systemd (of
> course, I think it would be better if such a thing went upstream
> whether right away or eventually).

No, and I don't agree it's a problem.

If you want to argue this upstream, feel free to, but I think taking the
«we must support /usr/local at the same level as /usr» is not
sustainable and not worth spending much time on.  There's a trivial way
to accomplish what you want, at runtime, unlike changing the PATH for
init.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are