Michael Stapelberg writes ("Re: [Pkg-systemd-maintainers] Bug#732981: ExecStart
et al should be capable of honouring PATH"):
> I asked in #systemd on IRC about this.
Thanks.
> Lennart replied that using $PATH makes it easy to end up running a
> binary that is not the one the service file author had in mind.
> [etc.]
I'm not really convinced by this.
> Furthermore, it is hard to provide a consistent $PATH to all service
> files, yet avoid deadlocks. An example he provided is having /usr/local
> on autofs, which can cause deadlocks when used in $PATH.
I don't think that works in Debian right now. I would be surprised if
it ever has. I imagine there are other workarounds possible.
> udev rules are another place where absolute paths are used.
I think this is plainly a bug.
> > Programs called from maintainer scripts should not normally have a
> > path prepended to them. Before installation is started, the package
> > management system checks to see if the programs ldconfig,
> > start-stop-daemon, and update-rc.d can be found via the PATH
> > environment variable. Those programs, and any other program that one
> > would expect to be in the PATH, should thus be invoked without an
> > absolute pathname. Maintainer scripts should also not reset the PATH,
> > though they might choose to modify it by prepending or appending
> > package-specific directories. These considerations really apply to all
> > shell scripts.
>
> 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.
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).
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
