<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 5, 2018 at 10:32 AM Ian Jackson <<a href="mailto:ijackson@chiark.greenend.org.uk">ijackson@chiark.greenend.org.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So I promised that I would summarise.  I found that trying to write a<br>
summary involved me doing a bit of research, and that not everyone in<br>
the thread seemed to agree about everything.  To make a coherent<br>
picture I had to make some suppositions, which may well be wrong.<br>
<br>
So I'd appreciate a review of the draft summary/conclusions below.<br>
<br>
<br>
Clear recommendations from the thread:<br>
<br>
Don't provide libpam-systemd.<br>
Do provide a separate pam module, rather than pam_systemd.so.<br>
File bugs against packages whose dependencies must be updated.<br></blockquote><div><br></div><div>I agree providing libpam-systemd is wrong. As noted elsewhere on this thread, libpam-systemd provides two related services:</div><div><br></div><div>1. systemd-logind integration</div><div>2. systemd --user integration</div><div><br></div><div>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.</div><div><br></div><div>I'll leave the hard problem of naming the packages to others :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Conflicts and/or switchability:<br>
<br>
There was a suggestion that libpam-elogind should Conflict<br>
libpam-systemd, to avoid complicating debugging or situations where<br>
they might interfere.  Conversely it was suggested that this might<br>
impede switching init systems by installing different sets of<br>
packages, although it's not clear to me whether this is actually a<br>
problem.  There was one suggestion to write yet another pam module<br>
which would switch between pam_elogind and pam_systemd according to<br>
whichever was available.<br>
<br>
I think experimentation will show which of these approaches is best.<br></blockquote><div><br></div><div>Won't elogind have to conflict with systemd anyway? Or how could the same dbus name be owned by multiple providers?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On the meaning of dependencies on libpam-systemd:<br>
<br>
Some people suggested that usually a dependency on libpamd-systemd<br>
would usually imply a dependency on systemd --user.  Having looked at<br>
the packages in question (searching sid for Depends or Recommends<br>
only) that seems to sometimes be the case, but only rarely.<br>
<br>
Looking at the list I think a manual review of the proposed MBF list<br>
would be sensible (and of course there would be a formal MBF proposal<br>
here on -devel) but in most cases testing would not be needed.<br></blockquote><div><br></div><div>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.</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><br>Saludos,<br>Felipe Sateler</div></div>