Re: upstart: please update to latest upstream version
Michael Biebl <biebl@debian.org> writes:
> Am 07.03.2012 23:34, schrieb Michael Biebl:
>> On 07.03.2012 22:46, Steve Langasek wrote:
>>> On Wed, Mar 07, 2012 at 10:24:39AM +0100, Michael Biebl wrote:
>>>
>>>> It's rather easy to confuse upstart's process tracking. You
>>>> explicitly have to tell upstart if a daemon forks once or twice
>>>> (expect daemon, expect fork) and if the daemon forks multiple
>>>> children upstart often doesn't get it right.
>
> [...]
>
>> Especially the dbus type is very neat. I don't think upstart supports
>> something similar like that.
>
> Reading through my message again, it seems I managed to turn that
> discussion into systemd vs upstart (again). That's something I down
> want and I'm not interested in, so I'm sorry for that and I hope we
> can just leave it at that.
>
> What I'm actually interested in, is how we can get away from sysvinit
> to something more suitable for todays needs while solving the problem
> for our non-Linux ports.
There won't be a switch in Debian to just ONE new init system. There are
too many people insisting their pet init must be the ONE. So give up on
the idea on replacing sysvinit and start thinking about being an
alternative to sysvinit. That also has the benefit that you can let the
non-linux ports figure out what they want to do themself and let them do
the work.
So step 1: Acknowledge that Debian will have to support more than one
init and sysvinit will remain for the time being.
Step 2: getting your pet init into Debian as alternative to sysvinit.
One thing discussed was having a common init description file (could be
one of the existing formats or something new) and generating sysvinit,
systemd or upstart config files from those. So think about it and record
all the information needed for each init system and come up with a
format for the common init description file. A good idea was to only
cover the most common cases and leave the too complex cases to ship
indivual configs for each init.
Then think about how to deploy them.
1) Ship init config in all formats in the package in parallel
This would be nice at least for really hard cases where the common init
description file is too hard to write. But this could generally be done
and the init configs would be generated at build time if a common init
description file exists. E.g. dh_installinit could automate this.
2) generate init config at install time
Alternatively you could ship the common init description file in the
package and generate the right init config during install. Probably the
best way for this would be to use file triggers. The package just drops
the config in /usr/share/common-init-files/ and sysvinit, upstart and/or
systemd install a trigger that then generated the right config for them.
For extra credits think about allowing multiple init system to be
co-installed. There could be an option to boot with init=sysv,
init=upstart or init=systemd. That would certainly make it simpler for
users to try out a new init.
Step 3: removing sysvinit
Then simply wait a few years for the new init system to catch on and
sysvinit supporters to die out. If you are right that your pet init is
the future then sysvinit will just fade away and can be removed.
MfG
Goswin
Reply to: