Should libpam-elogind Provide libpam-systemd ?

[Felipe Sateler]

On Mon, Nov 5, 2018 at 10:32 AM Ian Jackson <ijackson at chiark.greenend.org.uk>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20181106/7a660013/attachment-0002.html>