[bryanlarsen]

The headline is inflammatory and misleading. IIUC, flatpak is not depending on systemd as a whole, they're depending on a new component called systemd-appd, which does permissions stuff. This will allow alternate implementations, like how elogind grew out of systemd-logind.

IOW, it is an API + a spec, just like what you're asking for. But it's implementation first, because any API + spec designed by committee rather than being driven by an implementation universally sucks.

[gatlin]

How do I install only systemd-appd?

[bryanlarsen]

systemd-appd doesn't exist yet.

[bigbadfeline]

> systemd-appd doesn't exist yet.

This avoids the question, apparently because the design of this part makes it certain that when it does come into existence, it will depend on the rest of systemd.

The problem with systemd is that it's purposefully designed to be a viral monolith, without this it's got no purpose. We've been with this long enough to pretend otherwise.

[ecnahc515]

> The problem with systemd is that it's purposefully designed to be a viral monolith

Is it though?

Systemd is a project, not just a piece of software. It's got a lot of libraries that are reused across the different components that the systemd project ships. It's not that different from how most C/C++ projects have their own standard library built on top of stdlib/boost/etc. Any new "systemd project" could be done as a completely standalone piece of software, but it would mean recreating a lot of the libraries that already exist.

The biggest piece of coupling to systemd isn't really specifically systemd itself but how systems rely on how systemd does certain things, namely, cgroups. No one wants to manage cgroups themselves, so they use systemd to start services and put them into the cgroup hierarchy, etc. This is exactly one reason desktop environments "rely on systemd" (among others).

Why does everyone want to use cgroups (and thus systemd)? Because it makes managing groups of processes easier, which is directly tied to handling user sessions, which as it turns out, is something most applications want, since typically they deal with users!

Now, systemd's own sub-projects, (eg appd), are likely to be yet another consumer of systemd for similar reasons.

Using systemd, and building on top of it makes it much easier to implement features without having to do everything yourself.

[bryanlarsen]

It's not a monolith, which is obviously true because there is no distribution that ships all of it turned on by default. Fedora comes close, but most other distros pick and choose which parts of systemd to use.

systemd-appd will likely depend on some but not all of the rest of the systemd system.

But the original question is beside the point -- systemd-appd will provide an API that can be implemented by others. I doubt the questioner actually cares much about how much of systemd systemd-appd pulls in, they want none of it.