[arch-general] The future of sysvinit in Arch: Call for Help
teg at jklm.no
Thu Sep 27 09:48:06 EDT 2012
As the move to systemd is under way, and we will soon have packages in
our repos that require your system to be booted with systemd, I
thought this would be a good time to summarize the state of
sysvinit/initscripts in Arch and their future.
Abstract: I think the current state is relatively good (but I'm
clearly very biased) and it should not be hard to maintain a
non-systemd boot on Arch even in the long-run. However, someone has to
do the work.
NOTE: Please let's keep any replies on-topic. This is NOT about
whether or not sysvinit or systemd is good or bad.
This has been repeated a lot, but I think it makes sense to say it
again: We are quickly running out of people who do early testing of
initscripts. I.e., who follow arch-projects, review patches and test
initscripts-git. At some point we will probably also struggle with a
lack of developers/TU's testing initscripts in [testing], so if you
feel passionately about a non-systemd boot on Arch, please join
arch-projects and help with testing.
Initscripts are currently fully supported and actively developed. Work
has been going on for a long time to make initscripts and systemd
share the same configuration file format wherever that makes sense,
and this work is mostly completed (at least on the initscripts side).
Moreover, code is shared between systemd and initscripts wherever
possible (there might still be more opportunities for this, but the
work is mostly completed). Together, these two developments should
make it relatively easy to maintain initscripts for Arch in the
long-run, even with a small user/developer base.
I intend to maintain initscripts in the official repos as long as this
makes sense. However, for this to be viable, I think we would need at
least one capable and active initscripts developer who is interested
in helping out and who uses sysvinit/initscripts as their main init
system. In the long-run it would make sense for such a person to take
over maintainership of initscripts. Anyone interested, please join
arch-projects and post reviews, suggestions and patches :-)
Packages requiring systemd
In the (near) future, we expect some packages to no longer support
non-systemd boot. In particular I'm thinking of polkit, networkmanager
and some gnome packages (I don't know which as I don't use gnome
myself). There will probably be more in the future. We might also drop
ConsoleKit from the repos at some point in the future.
No need to panic though. The number of packages that will actually be
need to be rebuilt to support non-systemd boot are actually very
limited (certainly less than ten). An alternative repository just
providing the relevant packages could very easily be maintained by one
committed person (possibly even the same person that will help out
with initscripts). I would be happy to help with getting this started
if anyone is interested.
A point to keep in mind is that the people who don't want to switch to
systemd, might not be using ConsoleKit, polkit, etc anyway, so maybe
this problem is not actually a real one.
Currently we have a few hundred rc scripts in our repos (the scripts
under /etc/rc.d/) shipped with our various packages. This will
probably not change in the near future, but if for whatever reason
some packagers decide to drop some rc scripts from their packages (and
rely purely on the systemd unit files), then it would be very simple
to pull the relevant scripts from our repos and ship them in a
rc-scripts package in the above suggested repository.
As I have tried to outline above, the amount of work required for a
non-systemd boot is really small, and I'd be happy to help anyone who
decides to take it on. However, I have seen some suggestions of ways
of avoiding systemd that entails splitting the systemd package up,
rebuilding tens of packages just to avoid a systemd-libs dependency or
re-duplicate all the code shared between initscripts and systemd.
This, in my humble opinion, is not worth the effort and is not
something I'd be interested in getting involved with.
Please direct any technical discussions to arch-projects at archlinux.org.
More information about the arch-general