Work on init systems (was: Making -devel discussions more viable)
On Wed, May 09, 2012 at 12:29:21PM +0300, Arto Jantunen wrote:
> Thomas Goirand <zigo@debian.org> writes:
>
> > But that's not the problem. The issue is that there's no
> > outcome, and that it's demotivating. If I read others that
> > what we want to work on isn't a good idea, I will simply
> > not work on that, and external contributors will run away.
>
> I agree with this. The init system discussion has gone on long after it
> was useful, and instead of discussing the matter we should be working on
> implementing what we want to implement. As an example, if you want to
> see OpenRC in Debian, make it work and upload it. If someone else wants
> to see systemd in Debian they can make it work and upload it (as has
> been done).
This is exactly what is happening. I'm still involved with talking
about this with the OpenRC upstream folks on their IRC channel, and
while I've not yet had a chance to begin packaging it, there's a
repo on collab-maint in preparation for that. In order to make
OpenRC usable in Debian, we need it to be able to work with LSB
scripts, but it's not yet clear on how to do that. An upstream
developer was initially keen to look into doing this, but it looks
like they are now short on time, so we might need to do that part
ourselves in collaboration with them.
I'm short on time myself, so if anyone wanted to join in with
doing this, I'm sure we could set up a proper mailing list and
start moving things a bit faster.
> I think the only technical decision that needs to be made at this point
> is removing the Essential mark from sysvinit. The consensus for that
> should be somewhat more reachable, even if the technical implementation
> may have some open questions.
This is already in the works. It can be removed right now. The only
thing stopping it is just investigating the impact on removing the
Essential flag on the installer etc. If there are no deleterious
consequences of this change, it can be made in the next upload. Any
advice on doing this would be appreciated, e.g. in case this would
make it more liable to cause breakage if apt could remove sysvinit
and result in a broken system.
> In addition to that it would be nice if everyone could agree to not work
> against a certain init implementation (for example by refusing to
> include the startup file for that init when someone else has written one
> and submited it as a wishlist bug). We should however not demand that
> people work on writing startup files for init systems they don't care
> about.
AFAIK this is exactly what's happening. While I've been working on
sysvinit I've made numerous changes to better accommodate systemd and
upstart, and with the latest experimental uploads it includes some
changes to better work with upstart. There's no blocking involved--
I've been happy to make changes that improve things for alternative
init systems, and make migration easier, while also making things
better for everyone. So long as it doesn't have a negative impact
on existing sysvinit users, no changes have so far been refused.
While I have personal reservations about making systemd or upstart
the default at this time or in the near future, I am nevertheless
keen to make their support in Debian top-notch, and I will continue
to work on reorganising sysvinit to make this even better.
WRT supporting multiple init systems, I certainly don't think it's a
wise move for packages to support multiple init systems. If we
change the default, we should e.g. provide a means for sysvinit to
run systemd service units to allow for a smooth migration, and
amend policy so that all packages provide files in the same format--
we don't really want to have fragmented support for different
systems within Debian, though supporting different init systems as
the present is needed and desirable.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Reply to: