On Mon, Dec 02, 2013 at 11:24:41AM -0800, Russ Allbery wrote: > Steve Langasek <vorlon@debian.org> writes: > > Note that the original complaint in the samba upstream discussion was > > about hard-coding of paths to system utilities, which a) is not portable > > between distributions and b) contradicts Debian policy. > > So systemd upstream may support separate /usr, but that doesn't change > > the fact that there are still portability issues when one starts writing > > systemd units. > They're fairly trivial ones, though, no? Maintaining a local patch to > change the paths in a systemd unit is certainly way less effort than > maintaining the whole unit. It's akin to changing the #! paths in > installed scripts, which we do all the time. In this case, the porting requirements are trivial, yes. My point is that porting is still required, and systemd units aren't "write once, run everywhere" the way systemd advocates have claimed. In my experience, the cost of a packaging delta is in *maintaining* the delta over time, not in creating it initially, and a one-line delta to something like a systemd unit is not measurably less of a maintenance burden than, say, a 20-line delta to an init script. > (I should say, for full disclosure, that I have never been a fan of the > implications of our "always use PATH" policy for init scripts anyway. I > feel like init scripts or the equivalent should always start the same > binary, regardless of what other things the system administrator has > installed elsewhere on the system, unless explicitly changed by the > administrator. Having them honor PATH is too likely to lead to really > strange and difficult-to-diagnose problems, since you get different > behavior when manually running the init script versus when it's started at > boot.) Sure. Both systemd and upstart manage to avoid the problem of inconsistent behavior due to tainted admin environments, because daemons are always started as children of init and not of the admin's login shell. That being the case, hard-coding the path to an executable in your initscript equivalent doesn't buy you much added protection, compared with just using the system $PATH, and does cause gratuitous incompatibilities in exactly those cases that Debian Policy's prohibition on hard-coded paths is meant to address. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature