On Mon, Nov 5, 2018 at 10:32 AM Ian Jackson <[email protected]> wrote:
> 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. -- Saludos, Felipe Sateler
