The Debian init system general resolution returns

Posted Oct 24, 2014 3:59 UTC (Fri) by dlang (guest, #313)
In reply to: The Debian init system general resolution returns by xz
Parent article: The Debian init system general resolution returns

There is a difference between depending on systemd and distro packaging not being optimal for not having some systemd packages loaded on the system.

The first requires coding to fix, the second just requires packaging changes.

Since the systemd advocates have less than zero interest is supporting anyone not using systemd, it's not at all surprising that the packaging of the software drags in extra stuff

After all, it's the advocates who become package maintainers, they are interested in making that package work, not in supporting other packages working without their favourite software. It takes extremely mature maintainers to support that level of compatibility. This isn't the dig against systemd maintainers that it may sound like, _very_ few packages have maintainers or project leads that think about how people who don't use their whole package should be supported, either by breaking out components that are useful to others, or in terms of how users will be able to migrate cleanly away from the software.

The Debian init system general resolution returns

Posted Oct 24, 2014 9:44 UTC (Fri) by anselm (subscriber, #2796) [Link]

Packaging software pretty much always involves tradeoffs.

It would probably be possible to divide the “systemd” package on Debian into a number of packages that split out library support, etc. However, given that systemd is the designated default init system for Debian, we can reasonably expect that in the future a majority of Debian systems will run systemd. This means that for most users, splitting systemd into a number of packages that will all be installed doesn't really add value – it mostly makes extra work for the package maintainers and increases the probability of bugs.

For those who don't run systemd as PID 1 but still need the package installed for the libraries, a few extra files likely won't make that much of a difference, and if at some point a reasonable case for separating out some functionality emerges (say, when kdbus becomes popular) then the package can still be split.