The "Devuan" Debian fork

Posted Nov 30, 2014 12:03 UTC (Sun) by krake (guest, #55996)
In reply to: The "Devuan" Debian fork by mpr22
Parent article: The "Devuan" Debian fork

I always wondered why the "tight coupling with init" issue has not simply been solved by providing two systemd "start"packages: a systemd-init package that makes systemd the init and a system-notinit package that installs a start script for other inits.

The systemd package would depend on these as alternatives. People with any other init would install the second package, thus keep their init as-is but still solve all dependencies higher up.

But of course, if as you say the goal is to not run systemd at all, then this would not help.
However, why then phrase the discussion in terms of init when this is not actually the contended issue?

The "Devuan" Debian fork

Posted Nov 30, 2014 14:59 UTC (Sun) by amonnet (guest, #54852) [Link] (1 responses)

You are so true that's precisely what has been implemented in debian : meta package init (essential) depend on systemd-sysv | sysvinit-core | upstart

You are also true that's not enough for some.

The "Devuan" Debian fork

Posted Dec 2, 2014 17:52 UTC (Tue) by krake (guest, #55996) [Link]

Ah, interesting, thanks!

The "Devuan" Debian fork

Posted Nov 30, 2014 20:29 UTC (Sun) by dlang (guest, #313) [Link] (1 responses)

perhaps because a systemd-lite that only did the init work doesn't achieve the goals of the systemd team of taking over all the linux plumbing layer??

after all, what's uselessd other than systemd-lite?

It's a bit more than just packaging in that it disables some things that systemd has declared unavoidable (such as the journal and cgroups), but it does seem to be the equivalent of the systemd-lite that you are asking for.

The "Devuan" Debian fork

Posted Dec 2, 2014 17:51 UTC (Tue) by krake (guest, #55996) [Link]

> perhaps because a systemd-lite that only did the init work doesn't achieve the goals of the systemd team of taking over all the linux plumbing layer??

I am afraid I don't understand how this fits into the context of my question/puzzlement.

Having a package that runs systemd as a service fits the goal of having systemd providing the plumbing and the goal of using something else as init.

The alternative mechanism would allow people to go for a system which uses systemd for init and plumbing and other people for using anything else for init.

If I understood amonnet's posting above correctly, that actually exists.

Which just makes the "tight coupling" claim even more weird.