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

Regards,


Reply to: