Control: tags -1 - moreinfo Simon,
Many thanks for this. On Fri, Aug 09, 2019 at 02:35:13PM +0100, Simon McVittie wrote: > Control: tags -1 + moreinfo > > On Mon, 25 Feb 2019 at 10:58:49 +0000, Mark Hindley wrote: > > For desktops to be installable on such systems, policykit-1 needs to depend > > on > > the newly approved virtual packages default-logind and logind. In the latest > > upload of src:systemd, libpam-systemd provides default-logind. > > Sorry for the delay in getting back to you on this. Non-critical changes > to important components like policykit-1 did not seem like a good idea > during the buster release freeze. Yes, I understand that. It also seems to me that now, early in the bullseye cycle, is a good time for such changes. > Does polkit work correctly on systems that use elogind, without any > further source or binary changes? It is not enough that a logind-like > service is merely installed and monitoring sessions: to keep polkit's > core functionality working, it has to be able to query logind's state > via libsystemd.so.0 APIs. Yes, it works in my testing. I have had a number of other reports of success too with a variety of desktops (xfce, mate, budgie, cinnamon and even gnome). Since #923244 was resolved in version 241.1-1+debian1, libelogind0 is ABI compatible with libsystemd0 and exposes the same symbols for runtime linking, although providing a subset of functionality. This is explained fully in the libelogind0 package description: sd-login(3), sd-bus(3) and sd-id128(3) APIs are implemented in full with most other functions returning -ENOSYS. libelogind0 also provides a libsystemd.so symlink so that applications compiled against systemd work with libelogind0 at runtime. > For example, when polkitd calls sd_pid_get_session(), if the system is > using elogind, the API call needs to return whether pid is part of an > elogind session. > > Please could you describe how this is meant to work on systems that use > elogind? Which packages are meant to be installed to make this work? > > For comparison, here is how it works on systemd systems: > > - libpam_systemd is invoked on login and logout > - libpam_systemd communicates with systemd-logind to update its knowledge > of login sessions > - polkitd is linked to libsystemd.so.0, which is provided by libsystemd0 > - libsystemd0 communicates with systemd-logind via D-Bus, or by reading > files in /run/systemd that are considered private to the combination > of systemd-logind and libsystemd0 (mainly /run/systemd/seats and > /run/systemd/sessions, I think) > > Which parts of that architecture get replaced when using elogind? In exactly the same way. libpam-elogind is invoked at login/logout and updates elogind's record of sessions. polkitd calls functions in libelogind.so via its libsystemd.so symlink to retrieve information on users, sessions and their related processes. > When a bug is reported in policykit-1 on a system that is using elogind, > does the reportbug-generated message template indicate that? Is there > someone among the elogind maintainers who can help with such bugs if > they appear to be integration issues between policykit-1 and elogind? > > (If the reportbug-generated message template with your proposed patch > doesn't currently indicate systemd-logind vs. elogind, it should be > possible to fix that by putting appropriate runes in > debian/policykit-1.bug-control.) I will be very happy to work to resolve issues related to elogind and its integration with other packages. You are correct that a reportbug template including that information would be useful. > > There is a separate issue about backend support for elogind. I will > > open a separate bug for that. > > Does that separate bug exist, or has the question of backend support > become irrelevant due to changes in the design of how elogind fits into > Debian since you opened this bug? Yes that was #923244 which has now been solved by runtime ABI compatibility rather than the original suggestion of alternative backend packages. > On Fri, 09 Aug 2019 at 14:15:17 +0200, Svante Signell wrote: > > Please explain your decision on why desktops for other > > init systems are excluded (even in sid). > > Please don't assume that the absence of action is a deliberate decision. > All of policykit-1's maintainers (both upstream and in Debian) mostly > work on other things and don't have a huge amount of time available for > policykit-1. This makes us reluctant to risk creating the possibility > of non-functional combinations of packages that will take more of our > time to debug. I understand. To help prevent that libelogind0 conflicts with systemd itself so that the non-functional situation of systemd with libelogind0 is not possible. Thanks and best wishes. Mark
