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.
I agree providing libpam-systemd is wrong. As noted elsewhere on this thread, libpam-systemd provides two related services:
1. systemd-logind integration
2. systemd --user integration
Therefore I think we need two virtual packages, to signal the dependency on each service. That way, libpam-elogind can provide the first one but not the latter. Packages requiring (or wanting) can Depend (or Recommend) the latter. As usual for multiple providing packages, there should be a default-foo alternative listed first.
I'll leave the hard problem of naming the packages to others :)
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.
Won't elogind have to conflict with systemd anyway? Or how could the same dbus name be owned by multiple providers?
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.
Sometimes it might me a bug, sometimes not. I think having both virtual packages, and filing bugs when the systemd --user integration is not required/too strictly enforced is the right solution.