The Debian init system general resolution returns

Posted Oct 24, 2014 2:41 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
In reply to: The Debian init system general resolution returns by xz
Parent article: The Debian init system general resolution returns

Ah, I get it. You think that the dependency on systemd package means that you must use it.

That's incorrect, libpam-systemd simply needs some files packaged in the systemd package. It doesn't require it running.

To actually activate systemd on Debian one needs to install the systemd-sysvinit package (or manually specify it in the kernel command line).

The Debian init system general resolution returns

Posted Oct 24, 2014 3:38 UTC (Fri) by xz (guest, #86176) [Link] (4 responses)

If I don't use it, can I uninstall the package? No.

Is the package designed for being installed without being used? No.

As Chapman pointed out, libpam-systemd is explicit patched in Debian to start logind on demand. Therefore libpam-systemd depends on and actively uses an integral component of systemd. If it is really as simple as using some files from the systemd package, why not put those files into libpam-systemd?

Or are you changing the definition of systemd? logind is not systemd! I know systemd the word can mean a lot of things.

P.S. who on earth think it is a good idea to start daemons from deep inside a library "on demand"?

The Debian init system general resolution returns

Posted Oct 24, 2014 3:59 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

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.

The Debian init system general resolution returns

Posted Oct 24, 2014 4:37 UTC (Fri) by mchapman (subscriber, #66589) [Link]

> P.S. who on earth think it is a good idea to start daemons from deep inside a library "on demand"?

The Debian systemd package maintainers, clearly.

As I pointed out, the upstream systemd code does not do this. If you use the upstream pam-systemd on a non-systemd system, it's a no-op.

The Debian init system general resolution returns

Posted Oct 24, 2014 4:44 UTC (Fri) by mchapman (subscriber, #66589) [Link]

> If it is really as simple as using some files from the systemd package, why not put those files into libpam-systemd?

Well, I think Cyberax is wrong there. It isn't as simple as "using some files".

pam-systemd uses the logind D-Bus interface, org.freedesktop.login1. Anything that implements that interface correctly should work with it, which is why Debian's libpam-systemd can work with systemd-shim.

The error here is in removing the "test if logind even appears to be installed" check. While that's probably the right idea, in that I suspect systemd-shim doesn't create the directory it looks for, it means that D-Bus activation now takes effect: it's made pam-systemd *require* a logind D-Bus interface, instead of failing gracefully if logind isn't present.