Simon,
On Sun, Jan 10, 2021 at 08:03:18PM +, 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
