Re: Should libpam-elogind Provide libpam-systemd ?

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

So I promised that I would summarise.  I found that trying to write a
summary involved me doing a bit of research, and that not everyone in
the thread seemed to agree about everything.  To make a coherent
picture I had to make some suppositions, which may well be wrong.

So I'd appreciate a review of the draft summary/conclusions below.


Clear recommendations from the thread:

Don't provide libpam-systemd.
Do provide a separate pam module, rather than pam_systemd.so.
File bugs against packages whose dependencies must be updated.

On Conflicts and/or switchability:

There was a suggestion that libpam-elogind should Conflict
libpam-systemd, to avoid complicating debugging or situations where
they might interfere.  Conversely it was suggested that this might
impede switching init systems by installing different sets of
packages, although it's not clear to me whether this is actually a
problem.  There was one suggestion to write yet another pam module
which would switch between pam_elogind and pam_systemd according to
whichever was available.

I think experimentation will show which of these approaches is best.


On the meaning of dependencies on libpam-systemd:

Some people suggested that usually a dependency on libpamd-systemd
would usually imply a dependency on systemd --user.  Having looked at
the packages in question (searching sid for Depends or Recommends
only) that seems to sometimes be the case, but only rarely.

Looking at the list I think a manual review of the proposed MBF list
would be sensible (and of course there would be a formal MBF proposal
here on -devel) but in most cases testing would not be needed.


On dbus-user-session:

There was considerable discussion of this.  It provides a session dbus
which is shared by all processes with the same uids.  So it differs
from (eg) dbus-x11, which provides one per graphical session.

This sharing of a single bus between different sessions is the purpose
of dbus-user-session.  Its maintainer says that its use of
libpam-systemd would not work with elogind and I see no reason to
doubt that.

When a package does not want, specifically, this sharing, the
dependency should be on
   default-dbus-session-bus | dbus-session-bus
or maybe the older form which I found in some packages in sid:
   dbus-user-session | dbus-x11
(xdg-desktop-portal-gtk).

The value of this feature is IMO questionable.  (As background, there
were assertions on -devel that modern GNOME (eg dconf) does not work
properly if the same user logs in twice in parallel.  I'm sure that
contributors to debian-init-diversity would regard such a situation as
a significant bug.  But that's out of scope right now.)

I looked for dependencies on dbus-user-session in sid and found only
these:
  pinentry-gnome3 (src:pinentry)
  pulseaudio
  rygel

Of these:

pinentry-gnome3 and pulseaudio seem wrong to me.  PINs should not be
shared between login sessions and sound control should be per-session,
not per-uid.

I'm not sure about rygel but it doesn't seem likely to me that this
dependency on dbus-user-session is necessary.  Perhaps there is
another way to implement this on non-systemd systems.

So I think we should probably file bugs right away against these three
(two at severity normal, one at severity wishlist inviting further
discussion).  I think also I may file a bug against lintian asking for
plain dependencies on dbus-user-session to get a warning.

Ian.