Re: upstart: please update to latest upstream version

[Tollef Fog Heen <tfheen@err.no>]

]] "Bernhard R. Link" 

> * Tollef Fog Heen <tfheen@err.no> [120223 22:21]:
> > ]] "Bernhard R. Link"
> > Your shell is most likely implemented in C, but it's not like you sit
> > down and have to debug it every other day.  Why do you assume that you
> > need to do so just because policy is encoded in .ini-like files instead
> > of shell scripts?
> 
> Because shell is general purpose (and well known) enough that you can
> modify it sensibly. In the long run systemd init support might grow its
> own language to be just another shell, but I guess until then of the
> typical quick-hack constructs like addings some echos, adding some
> cleaning code before, conditionally starting stuff, or multiple times
> until some condition is reached, with some filedescriptors redirected,
> with a strace or ltrace and things like that will not all possible in
> a way one can easily do.

I think you're approaching the problem from a somewhat weird direction.

systemd unit files are declarative.  There's no such thing as adding
echo to display a variable.  What you do is look at the state of a
variable because the units are introspectable.  I doubt we'll ever see
systemd units become procedural, but at the same time, I don't think
procedural definitions of services is something an init system needs.
Feel free to come up with counter-examples where that's actually needed,
though.

You can trivially add commands that are run before or after the daemon
in question.  You can, if you really want to, run complete shell
commands in the unit files.  It's not the usual case, nor is it ideal,
but you can if you need to.  Very few daemons actually need a
fully-programmable environment and so the common case is to just start a
binary and track any children of said binary.

The only issue you raise which isn't well covered today is that shell is
better known than the semantics of systemd units.  There's documentation
out there, but few administrators and developers know the system yet.
That will change, so I'm no too worried about that piece.

> What I try to say is "If there can only be one, then this should not
> be systemd. So if Debian shall have systemd, it should support
> multiple init systems."

We'll see about that, but it's not a battle to be held today, nor
tomorrow.

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