Simon, On Sun, Jan 10, 2021 at 08:03:18PM +0000, Simon McVittie wrote: > I wouldn't want to give a ruling that would be interpreted as precedent to > (effectively) overrule multiple maintainer decisions (whether they're > decisions by a single maintainer in multiple packages, or multiple > maintainers' decisions in multiple packages) without at least being aware > of how many packages and decisions we are affecting - similar to the > principle that when the Policy editors add a new normative requirement, > they usually want to know how many packages were compliant with the old > Policy but are considered non-compliant under the new Policy.
[...] > However, I think we would be reluctant to give a general ruling like that, > because it would not always be correct. systemd is quite featureful and > its interface is quite large (if I understand correctly, this is one of > the major things that people who would prefer a different init system > dislike about it). Different packages use different subsets of that > interface, sometimes larger[1] than the subset that can be provided by > elogind (because elogind closely resembles systemd-logind, and by design > the other parts of systemd's interface are outside its scope). The extent > to which the various parts of the interface are required by the dependent > package (whether they would be Depends, Recommends, Suggests or nothing, > if they were represented by separate dependencies) also varies. > > dbus-user-session is one concrete example of a package that needs a > working `systemd --user` instance per uid (a per-uid user-service > manager), and so will not do what its (informal) specification > says if it is forced to be installed on non-systemd systems - > so replacing its libpam-systemd dependency with > "default-logind | logind" would be incorrect. If that dependency > was replaced, the replacement would have to include something like > "libpam-systemd | libpam-start-dbus-daemon-per-uid", where the latter > doesn't currently exist. Of course you are quite correct that libpam-systemd provides access to 'systemd --user' which libpam-elogind does not and can not. In unstable the list of packages with a hard libpam-systemd dependency is now quite small. Both dbus-user-session (as you say) and gdm3 require 'systemd --user' and support for elogind has quite rightly been refused by the maintainers on that basis. nix-setup-systemd is clearly systemd dependent. 2 packages are empty metapackages[1] with specific purpose that I would not expect to support elogind. That leaves udisks2 and network-manager as the only outstanding packages in which elogind support is possible but unavailable. As in the case of network-manager, I can confirm that my testing of udisks2 shows it works with libpam-elogind without issue. Obviously Michael is maintainer of both pacakges. In the absence of public comment or engagement from him I do not want to infer his motives. However, the end of his submission to the tech-ctte relayed by Elana states > On Thu, Nov 19, 2020 at 09:04:00PM -0800, Elana Hashman wrote: [...] > elogind is very difficult to support in its current state (see the > following bugs: [2] [3] [4] [5]), which is why Michael does not want to > maintain support for it. I have already made the point that[2] the bugs he referenced have been addressed and do not represent a technical reason why elogind should not be supported. I completely understand that the tech-ctte would not want to make a ruling that could be over generalised. But I don't think that is what is being asked for (although Matthew may want to clarify this). This is about securing implementation of the GR result. If there is a technical reason which prevents a package working with elogind I completely agree that it would be wrong for it to make use of the logind virtual packages. Mark [1] progress-linux-base-system and debian-cloud-images-packages [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975075#224
