Hi, On 01.12.19 20:13, Russ Allbery wrote: >> Right, but the dependency chain is there to make sure the package is >> usable on systemd systems, i.e. we'd have to accept a regression for the >> systemd case in order to facilitate the non-systemd case, which is what >> we don't want, or live with unrelated packages changing people's init >> system, which we also don't want. > My recollection is that these dependencies are mostly about either making > sure user sessions are available or that D-Bus is available, right? (I'm > fairly sure about user sessions and less sure about D-Bus.) In that particular case, the user session must be available to allow activation of gsettingsd via dbus in the user session context, or gtk cannot save certain user settings, and silently discards them because there is no other method to save them included in gtk. dbus-x11 is not a complete solution -- it makes a "session" dbus instance available, but without dbus activation of services, the settings daemon must be started through some other mechanism so it is available. Without systemd, that mechanism would be "gnome-session". > Is it possible to have a systemd system that doesn't have these > properties? In other words, do these dependencies only matter with other > init systems, or do they also matter in container scenarios? I'd expect container scenarios with no user login capabilities, so it doesn't make sense to install dbus-user-session there, so there is a good reason why user-facing apps would have to declare that dependency, and it absolutely makes sense to do that centrally from a library that is only used by user-facing apps. The container scenario is an afterthought in both technology stacks, neither systemd nor traditional Unix do well here. If you run containers, you have your own orchestration framework at the top of the food chain, and whether that simply executes programs directly or asks systemd to do it for them is an implementation detail that might change between container hosts in the same installation. The container people most likely want minimal dependencies like shared libraries in the package system, but functional dependencies would cause too much software to be installed into a container. For example, if I write a service that logs through a dbus interface instead of syslog, I would not want an implementation of that interface inside the container, but on a dbus instance shared between containers. The Debian dependency mechanism cannot express this in a sensible way at the moment, the closest we can get is Recommends. So far, we haven't expressed service dependencies at all, because packages with such dependencies were only used in specific scenarios, e.g. a package that requires an SQL database to work would only document that somewhere and leave the setup to the sysadmin rather than pull in a database service as a package. Medium-term I'd expect that we have to create new dependency types: - Depends-DBus-System-Service - Depends-DBus-Session-Service - Provides-DBus-System-Service - Provides-DBus-Session-Service With demand activation through dbus comes the responsibility of the distribution to populate the local service registry before the activation request comes in. Our options there are preemptively installing services so they are registered, or adding a catch-all service that informs the user through a notification service that a certain package must be installed for a particular feature to work, which requires a (smaller) mapping of advertised[1] interfaces to packages required, both of which would likely be expressed through package relationships in Debian. Simon [1] https://docs.microsoft.com/en-us/windows/win32/msi/advertisement
Attachment:
signature.asc
Description: OpenPGP digital signature