The Debian technical committee vote concludes

Posted Feb 11, 2014 18:53 UTC (Tue) by dfsmith (guest, #20302)
In reply to: The Debian technical committee vote concludes by rahvin
Parent article: The Debian technical committee vote concludes

And they'd have good cause. B-)

Look at the dependency lists (1st level):

sysvinit (132kB): libc6, libselinux1, libsepol1, debianutils, initscripts, sysv-rc, sysvinit-utils

upstart (486kB): libc6, libdbus-1-3, libjson0, libnih-dbus1, libnih1, libselinux1, libudev0, sysvinit-utils, sysv-rc, initscripts, mountall, ifupdown, udev

systemd (1445kB): libacl1, libaudit0, libc6, libcap2, libcryptsetup4, libdbus-1-3, libkmod2, liblzma5, libpam0g, libselinux1, libsystemd-daemon0, libsystemd-id128-0, libsystemd-journal0, libsystemd-login0, libudev0, libwrap0, util-linux, initscripts, udev, dpkg

The Debian technical committee vote concludes

Posted Feb 11, 2014 19:11 UTC (Tue) by proski (subscriber, #104) [Link] (5 responses)

systemd depends on dpkg? I think it's some Debian technicality. It's not the case on Fedora :)

util-linux, initscripts and udev belong to a minimal system, so the dependency is a non-issue.

Dependencies of some libraries can be made dynamic. Yes, systemd is still a big thing, but so is a modern OS.

The Debian technical committee vote concludes

Posted Feb 11, 2014 19:20 UTC (Tue) by bluss (guest, #47454) [Link] (3 responses)

Those were stats for wheezy (stable), stats for jessie (current testing) are:

Version: 204-6
Installed size: 4984 KB
Depends: libacl1, libaudit1, libc6, libcap2, libcryptsetup4, libdbus-1-3,
libgcrypt11, libkmod2, liblzma5, libpam0g, libselinux1, libsystemd-daemon0,
libsystemd-journal0, libudev1, libwrap0, libsystemd-login0, util-linux,
initscripts, udev, acl, adduser
Recommends: libpam-systemd

The Debian technical committee vote concludes

Posted Feb 11, 2014 22:44 UTC (Tue) by anselm (subscriber, #2796) [Link] (1 responses)

The problem here is that systemd does various useful things by itself that the other inits either don't do at all or push into (optional) other packages that helpfully come with init scripts so there is no dependency on that package on the part of the init systems. If these other packages then depend on other stuff, that other stuff will not show up in the init's list of dependencies.

Chances are that if you examine the transitive closure over all dependencies rather than just the direct dependencies of the init system, the difference between a system based on systemd and one based on SysV init with the same functionality will no longer be all that great.

The Debian technical committee vote concludes

Posted Feb 14, 2014 10:16 UTC (Fri) by Wol (subscriber, #4433) [Link]

And are the daemon init scripts included in the source-line count etc?

I thought one of the major selling points of systemd was that a 100-line systemd init script was *huge*. For sysvinit that's miniscule, isn't it?

So while systemd itself may be pretty large for an init system, that is far more than compensated for by the reduction in size in packages that make use of it.

Cheers,
Wol

The Debian technical committee vote concludes

Posted Feb 14, 2014 8:20 UTC (Fri) by smurf (subscriber, #17840) [Link]

Note that some of these dependencies are not used by systemd itself, only by some of its helpers.

Of more interest is the main memory which systemd-as-PID-1 actually uses. That boils down to 2.8MB on my system, vs. 0.8MB for sysvinit. Compared with its long list of features, that's not bad at all.

The Debian technical committee vote concludes

Posted Feb 14, 2014 7:54 UTC (Fri) by smurf (subscriber, #17840) [Link]

It actually pre-depends on a specific minimum version of dpkg so that installation works correctly (dpkg moved a script).

The Debian technical committee vote concludes

Posted Feb 11, 2014 19:46 UTC (Tue) by dag- (guest, #30207) [Link] (1 responses)

Reading your list of dependencies, my conclusion is quite the opposite of what you are implying.

Only systemd understands ACLs (libacl), integrates with the auditing framework (libaudit), can use Linux/POSIX capabilities (libcap), integrates with crypted block devices (libcryptsetup), integrates with the recent kernel module interface (libkmod), integrates with PAM (libpam), integrates with udev (libudev), integrates with tcp_wrappers (libwrap).

This is all a good thing, since all of the above means richness and a full-featured init/xinet-system. What's worrying is that upstart doesn't seem to have the same integration. For sysvinit the above complexity (when available) is moved to the scripts on a case-by-case basis, with no consistency at all.

What I do not understand is why systemd is lacking SELinux support (libselinux/libsepol) maybe because it was disabled on build ?

The Debian technical committee vote concludes

Posted Feb 11, 2014 20:18 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

My fedora 19 system has systemd depending on libselinux. The lack of dep in the packaging could be due to an implicit depchain? Maybe something else in the deplist already pulls in selinux so the debian packaging didn't make it explicit?

The Debian technical committee vote concludes

Posted Feb 11, 2014 20:01 UTC (Tue) by vonbrand (subscriber, #4458) [Link]

Check also the slew of programs called from the rc scripts and the "libraries" of functions they call for a balanced comparison.

The Debian technical committee vote concludes

Posted Feb 11, 2014 21:10 UTC (Tue) by rodgerd (guest, #58896) [Link] (3 responses)

So the argument is now that:

1/ systemd is a blob that does everything.
2/ systemd has too many external dependencies.

The Debian technical committee vote concludes

Posted Feb 12, 2014 16:26 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] (2 responses)

I think the basic idea is that systemd tries to do too many low-level things that really ought to be broken up. That results in it being large by itself and it having a large number of dependencies.

The Debian technical committee vote concludes

Posted Feb 12, 2014 16:49 UTC (Wed) by HelloWorld (guest, #56129) [Link] (1 responses)

Well, the thing is that many of the things that systemd does aren't really at all exciting. Take things like systemd-tmpfiles, systemd-timedated, systemd-localed and so on. They're simple and they get the job done, so why shouldn't systemd ship them? The point is that the problems caused by diversity (e. g. application authors having to support different ways of doing the same thing) are greater than the benefits that can conceivably be achieved by replacing those parts.

The Debian technical committee vote concludes

Posted Feb 12, 2014 22:17 UTC (Wed) by vonbrand (subscriber, #4458) [Link]

... and those tasks are done in separate, small, simple binaries.

The Debian technical committee vote concludes

Posted Feb 12, 2014 11:57 UTC (Wed) by jond (subscriber, #37669) [Link]

A mere list of package dependencies is not useful without some context. What is the point you are making? You may need to spell it out. Not all packages are equal in size-terms, if that's your point.