[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: upstart: please update to latest upstream version

On Sat, Feb 25, 2012 at 1:44 AM, Russ Allbery <rra@debian.org> wrote:
>> 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
>> deal).
> 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.

In that case, either way seems fine to me.

>> 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.)

Indeed. What I meant is that we probably could support the most common
usage of /etc/default so that more sysvinit scripts could be converted
to be automatically generated from a declarative description. So yes,
those files in /etc/default would not be used by the services launched
by upstart/systemd. They would only exist so that everything would
transition smoothly to people stuck with sysvinit, even if the
maintainer chooses to get rid of manually created sysvinit scripts.


Reply to: