On Sat, 02 Jan 2021 at 18:36:23 +0000, Matthew Vernon wrote:
> While [lowering NM's dependency on libpam-systemd from Depends to
> Recommends] does address the co-installability of network-manager with
> elogind, I would like you to still say something officially about the issue,
> please, since this is not the only affected package.
>
> As an example, bug 923387 (which Michael is also maintainer of) for udisks2,
> where the dependency must be a Depends not a Recommends (so the workaround
> used for network-manager won't help).
If you intend the scope of this bug to involve overruling maintainers'
decisions in packages other than NM, what other packages/bugs did you
have in mind? Is it just udisks2/#923387, or are there more?
Speaking only for myself as an individual TC member, rather than speaking
for the whole TC, but I suspect others feel similarly:
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.
>From the original request, it seemed to me that network-manager was
considerably more important to you than other packages with systemd
dependencies, and so you were prioritizing a request to overrule that
particular maintainer decision, so we focused on network-manager. I'm
sorry if that was a misinterpretation.
Perhaps you were hoping we would give you a very general ruling like
"dependencies on libpam-systemd (must|should) always be replaced by
default-logind | logind" that is immediately applicable to all the
other packages you are interested in, and would have an effect similar
to overruling decisions in the other affected packages too, without us
having to specifically vote (with a 3:1 supermajority) to do so.
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.
smcv
