[arch-general] The future of sysvinit in Arch: Call for Help
Hi guys, 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. Testing ===== 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 ====== 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. rc scripts ===== 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. Concluding remarks ============ 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@archlinux.org. Cheers, Tom
Hi Tom, I had no time to read the complete mail, I'll do it ASAP. Is it possible to configure pacman to upgrade initscripts and related packages only from testing, but no other packages? Regards, Ralf
On Thu, Sep 27, 2012 at 6:46 PM, Ralf Mardorf
Is it possible to configure pacman to upgrade initscripts and related packages only from testing, but no other packages?
I don't think you can make pacman do that automatically (I think not). What you can do is add [testing] as your last repository in pacman.conf and install initscripts from there manually: $ pacman -S testing/initcripts You'll have to know when to do this though, as you won't get a notification when a new version hits testing. (NOTE: in general, this sort of cherry-picking from testing is discouraged as you might have out-of-date dependencies). What I do is to create an initscripts-git package and install that instead (obviously this is a lot more bleeding edge than [testing]): $ git clone git://projects.archlinux.org/initscripts.git $ cd initscripts $ makepkg $ pacman -U initscripts-git-20120927-c67d598-any.pkg.tar.xz Cheers, Tom
On Thu, Sep 27, 2012 at 03:48:06PM +0200, Tom Gundersen wrote:
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 :-)
A question about this: apart from changes such as those required to accomodate systemd or the /lib to /usr/lib migration, _what_ is actually involved in the day-to-day maintenance of initscripts ? In other words, what sort of events would mean they need to be modified ? Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Thu, Sep 27, 2012 at 11:11 PM, Fons Adriaensen
A question about this: apart from changes such as those required to accomodate systemd or the /lib to /usr/lib migration, _what_ is actually involved in the day-to-day maintenance of initscripts ? In other words, what sort of events would mean they need to be modified ?
Bugs. Changes to related packages (mkinitcpio, udev, lvm, mdadm, cryptsetup, util-linux, filesystem). You'd probably want to maintain compat with the systemd config files (so you'd not also need to duplicate all the documentation/wiki) so whenever they are extended support should probably be added to initscripts (as we now use the systemd tools this might be a rare occurrence). In short: One would just have to make sure to avoid general bit-rot as with any software. -t
participants (3)
-
Fons Adriaensen
-
Ralf Mardorf
-
Tom Gundersen