Bug#727708: systemd and support for other distros
Steve Langasek <vorlon@debian.org> writes:
> On Mon, Dec 02, 2013 at 11:24:41AM -0800, Russ Allbery wrote:
>> 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.
Hm. I guess what I can say there is that this doesn't match my
experience, mostly because the deltas that I've had to maintain to init
scripts are much more serious than path changes. Path changes are pretty
easy to maintain over time. Init scripts have historically required more
serious changes for different helper function libraries, using
Debian-specific tools like start-stop-daemon, and so forth. In fact, most
of my upstreams have long since given up on trying to write a portable
init script and just have separate ones for each major UNIX variant.
By comparison, path differences are trivial. As far as I'm concerned,
that still counts as "write once, run everywhere."
> 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.
I have never seen a gratuitous incompatibility caused by this. Do you
have any examples?
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: