Re: upstart: please update to latest upstream version
Fernando Lemos <firstname.lastname@example.org> writes:
> How about a converter from a different, init-agnostic format into the
> specific formats? That way we could specify stuff that's specific to
> each format, things such as:
> * Socket activation information for systemd (and possibly upstart with
> * Events emitted by upstart
> * Dependencies declared in the LSB header of the sysvinit script
> * Path to the pidfile for the sysvinit script
> * Invocation for the sysvinit script so that the process stores the
> pidfile at the specific location
> This file could be easier to parse than a upstart/systemd unit too. I
> think even more than scripts could be converted into this basic
> format. The only drawback I can see is that it's another init
> description syntax to learn (if it's simple enough, maybe it's not a big
Both systemd and upstart have extensible formats, so this would probably
be most easily done via extending one or the other of them rather than
inventing a completely separate format, I think.
> Lots of packages use /etc/default.
One of the big features of upstart (and I believe systemd as well) is that
this mostly goes away. There are better ways provided for most of the
things one currently has to use /etc/default for. For example, the
upstart scripts are small and simple enough that, unlike with init.d
scripts, it's meaningful and natural to expect the local administrator to
just edit it and change the flags passed to the program, rather than using
*_EXTRA_OPTS all the time, because the init file just doesn't change very
often. Unlike the current init scripts, which are complex messes and
change all the time.
(I'm still a *bit* dubious that this will work well in practice, but at
least the theory sounds great.)
> Then there's always oddball init scripts. I bet some of those can be
> fixed, some may be split into a wrapper script (which could also be
> invoked by upstart and systemd for even more reuse).
Yes, particularly with systemd I think wrapper scripts are very appealing.
> I can envision this converter being plugged into dh so that the init
> files are automatically generated. The maintainer could supply
> init-specific scripts for weird stuff that isn't covered by the basic
> format supported by the generator.
Yeah, that was roughly the conclusion we reached in the previous
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>