Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-27 Thread Sam Hartman


General arguments about how the TC should conduct its business do not
belong on this bug.
I'd appreciate it if replies to this message are directed to a different
place than this bug.

We've established that the TC is operating consistently both with its
historical process and with currently permitted behavior for a group of
Debian developers.
You're making an argument about what the TC's behavior should be that is
general, not specific to this issue.

Please make that argument in a general forum and do not tie it to this
issue.

You're also making an argument that has been made before without
choosing to avail yourself of the history of the discussion on TC
privacy.
My recommendation would be to find someone who agrees with you who has
followed that history and learn it--at least the parts of the history
that support your position.
Your argument would come across stronger if you did.

> "Felix" == Felix Lechner  writes:

Felix> Hi,
Felix> On Tue, Jan 26, 2021 at 5:48 PM Sandro Tosi  wrote:
>> 
>> the ability to talk privately with the committee is something
>> CTTE has allowed for a long time

Felix> Debian has many great traditions, but the Magna Carta is much
Felix> older. I found a great article about it ([1], p. 5):

Felix> "the simple human need for fairness, reflected in western
Felix> jurisprudence since at least 1215 when it was pronounced in
Felix> the Magna Carta, underlies the legal concerns about ex parte
Felix> communications during administrative decisionmaking
Felix> processes. Fairness certainly requires an impartial
Felix> decisionmaker, and often the appearance of impartiality can
Felix> become as important a factor in the legal review of fairness
Felix> as actual impartiality."

Fortunately for all of us, the TC is not a legal body, and this is not a
legal dispute process, nor does jurisprudence apply as a concept.

Yes, you can consider whether concepts from jurisprudence should wrap
over to Debian processes, but you need to actually justify that, and
consider the trade offs.
It is unsurprising to me that the trade offs for a legal process that
can deprive someone of property and life work out differently than the
trade offs for a body charged with choosing a technical path for an
operating system.
That's true even when people are emotionally invested in the outcomes.
Fairness is one thing that someone might value.
It tends to be highly valued in jurisprudence, but other things might be
valued more highly in a proceeding like the TC.
And you don't get fairness when the process is emotionally draining
enough that key stakeholders refuse to cooperate.



Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-27 Thread Felix Lechner
Hi,

On Tue, Jan 26, 2021 at 5:48 PM Sandro Tosi  wrote:
>
> the ability to talk privately with the committee is something CTTE has
> allowed for a long time

Debian has many great traditions, but the Magna Carta is much older. I
found a great article about it ([1], p. 5):

"the simple human need for fairness, reflected in western
jurisprudence since at least 1215 when it was pronounced in the Magna
Carta, underlies the legal concerns about ex parte communications
during administrative decisionmaking processes. Fairness certainly
requires an impartial decisionmaker, and often the appearance of
impartiality can become as important a factor in the legal review of
fairness as actual impartiality."

The State of Hawai'i publishes a simpler guidance prohibiting private
communications with a judge. [2]

Kind regards
Felix Lechner

[1] 
https://www.cacities.org/Resources-Documents/Member-Engagement/Professional-Departments/City-Attorneys/Library/2016/Annual-2016/10-2016-Annual_Calonne_Lets-Ex-Parte!-The-Limits-a.aspx
[2] https://www.courts.state.hi.us/self-help/exparte/ex_parte_contact



Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-27 Thread Gunnar Wolf
Sandro Tosi dijo [Tue, Jan 26, 2021 at 08:47:22PM -0500]:
> the ability to talk privately with the committee is something CTTE has
> allowed for a long time; it's a two-sided coin: it can prevent heated
> exchanges, but it can also leave a sour taste in the petitioner's
> mouth.
> 
> While i would tend to agree that it's slightly unfair, i've never been
> on the other side to judge it fully.

While we discussed the 2016/002¹ and 2016/004² GRs, about the
declassification of debian/private, we discussed the argument that any
group of people (and, certainly, any group of Debian developers) could
set up a private communication channel.

  ¹ https://www.debian.org/vote/2016/vote_002
  ² https://www.debian.org/vote/2016/vote_004

We do, yes, maintain some private communication while working
officially as the Technical Committee - and it's a known fact. We try
to maintain as little as possible contact with maintainers that are
part of a dispute... But sometimes, it's the only way to move
forward.

We have to acknowledge not all DDs have the same personal
skills. Disputes are draining for everybody, but some people might
find it even harder. Engaging directly with a person with whom you
already have a story of tension is something mnay people will do their
best to avoid.

So, yes, sometimes we will use private communications, and try to
serve as a channel between the parts through which the essence of the
communication, without the thorns and the pain, can better flow.

Of course, there is a committment that we will share the fact this
communication took place, and we will communicate the contents to the
community at large.


signature.asc
Description: PGP signature


Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-20 Thread Felix Lechner
Hi,

Sorry to comment so late. A meeting about this bug may already be in progress.

On Sat, Jan 16, 2021 at 4:15 AM Matthew Vernon  wrote:
>
> The maintainer won't talk to me, nor will they engage with me (or anyone
> else) on this thread, though they will it seems talk to the TC in private.

In most places, a failure to respond would result in a default
judgment for the aggrieved party—in this case Matthew.

Here, the situation here is more complicated. There was a private
communication with the committee, but such side conversations are
unfair: How can Matthew ever feel that justice was served? I would
personally not feel closure unless I saw all such communications and
had an opportunity to respond.

Secrecy, if it is really needed, should instead be implemented by
requiring all parties involved to keep sealed records confidential.

I urge the committee to please reconsider its willingness to engage
with one party without the other present. The dignity of the Technical
Committee—Debian's highest and most hallowed body—could suffer.

Thank you!

Kind regards
Felix Lechner



Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-18 Thread Sam Hartman
> "Russ" == Russ Allbery  writes:


>> I have not come to the TC to ask them to overrule the maintainer
>> frivolously nor before exploring as many other options as I
>> could.

Russ> I understand (oh, boy, do I ever) how strained relationships
Russ> are after the long-running init system battles, but it's very
Russ> hard to resolve problems without the TC when one of the
Russ> parties is unwilling to communicate.  There have been a lot of
Russ> other hostile and aggressive threads about init system issues,
Russ> but this specific bug is not one of them as far as I can tell.

Russ> I don't want to force anyone into communicating when they
Russ> don't want to (general rule 2.1.1), but then I think they need
Russ> to welcome NMUs or a co-maintainer who can deal with the
Russ> things they don't want to have to think about or *something*.
Russ> This kind of silent treatment is really demoralizing to other
Russ> people in the project who are not at fault for any of the
Russ> historical init system hostility.

I'd like to second Russ's analysis here.  I was DPL during a chunk of
the relevant time, and was not able to get communication happening even
when relevant parties (Mark in particular) were being constructive.

I totally understand being burned out on the issue of init systems.
I totally understand being a maintainer who doesn't want to deal with
that.
I think the solution Russ proposes is right in that situation: find
someone you trust to NMU or act as a co-maintainer to move things
forward.

I think it is entirely reasonable for the TC to consider factors like
whether a maintainer is  willing to do that.

Yeah, it sucks when we override a maintainer.
Yes, that's demotivating.

So is creating a situation where people who are being constructive
cannot even engage.
It's one thing to engage with a maintainer and have them consider your
arguments and disagree.
It's another thing entirely when people are trying to work
constructively within the spirit of a GR that we as a community passed
and cannot even get their contributions considered.

That drives people away and  discourages Debian from growing.
I don't think we want that culture.


signature.asc
Description: PGP signature


Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-17 Thread Matthew Vernon

On 17/01/2021 10:29, Andreas Henriksson wrote:


Possibly getting off topic here, but I happened to read a bit of this
discussion and while seeing your comment I thought it might be a good
time to remind you about #934463.


I agree it's off-topic here, so I've sent a message to that bug 
suggesting an approach.


Regards,

Matthew



Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-17 Thread Andreas Henriksson
Hello Matthew Vernon,

On Mon, Jan 11, 2021 at 09:07:03PM +, Matthew Vernon wrote:
> [...], and while I hope your ruling will not result in a bonfire of
> perfectly good init scripts, I hope that maintainers who decide to
> ditch them will let us know so we can add them there
[...]

Possibly getting off topic here, but I happened to read a bit of this
discussion and while seeing your comment I thought it might be a good
time to remind you about #934463.

While I'm no longer maintaining the relevant package, I don't think
you should expect the current situation to persist for as many years
as we've already been carrying this for you. You have been let known,
so please spare us from receiving rage once it actually happens.

(I'd personally also be very happy if we could see some movement on
a bunch of other sysvinit bug reports that is relevant even for
non-sysvinit users, which would at the same time give me more confidence
in that it's useful to engage in discussion like this at all.)

Regards,
Andreas Henriksson



Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-16 Thread Russ Allbery
Matthew Vernon  writes:

> The maintainer won't talk to me, nor will they engage with me (or anyone
> else) on this thread, though they will it seems talk to the TC in
> private.

> I think, though, that it is common ground between submitter and
> maintainer that the Depends is necessary for udisks2 (unlike in
> network-manager where it turned out not to be).

> There was some discussion about whether elogind works with udisks2 in
> early 2019 and again in early 2020. On 2020-03-15 Nils draws the
> maintainer's attention to the explicit mention of elogind support in
> udisks upstream changelog.

Looking at this bug, I agree with Matthew: there is no indication that I
can see in the bug discussion that the solution proposed there would not
work.  I can speculate about why the maintainer may have not wanted to
change the dependency, but it's somewhat pointless to do so in the absence
of any additional information.

There may be some Policy work necessary to make it clear that this
dependency can also be used for packages that use the C ABI, not just the
D-Bus ABI, but I don't see any clear reason why that should block this
change.

If the question is one of maintainer support, adding some note in
README.Debian or in a reportbug prescript to say that only systemd is
directly supported by the package maintainer and problems on non-systemd
systems will require someone else to step forward to analyze and help with
the problem feels like a better solution for the project as a whole than
not changing the dependency.

> I have not come to the TC to ask them to overrule the maintainer
> frivolously nor before exploring as many other options as I could.

I understand (oh, boy, do I ever) how strained relationships are after the
long-running init system battles, but it's very hard to resolve problems
without the TC when one of the parties is unwilling to communicate.  There
have been a lot of other hostile and aggressive threads about init system
issues, but this specific bug is not one of them as far as I can tell.

I don't want to force anyone into communicating when they don't want to
(general rule 2.1.1), but then I think they need to welcome NMUs or a
co-maintainer who can deal with the things they don't want to have to
think about or *something*.  This kind of silent treatment is really
demoralizing to other people in the project who are not at fault for any
of the historical init system hostility.

-- 
Russ Allbery (r...@debian.org)  



Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-16 Thread Matthew Vernon

On 16/01/2021 01:39, Gunnar Wolf wrote:

Matthew Vernon dijo [Mon, Jan 11, 2021 at 09:07:03PM +]:



Please overrule the maintainer in #923387 so that it is can be used on
systems with elogind; it has been tested and shown to work thus as well as
being supported by upstream[1].


As it was mentioned on a previous mail to this thread, this discussion
on including an elogind dependency was done WRT network-manager. An
agreeable solution was brought forward by the maintainer. #923387
(udisks2) was just mentioned in this discussion. Maybe an amicable
solution can be tried before asking the TC outright to overrule the
maintainer?


The maintainer won't talk to me, nor will they engage with me (or anyone 
else) on this thread, though they will it seems talk to the TC in private.


I think, though, that it is common ground between submitter and 
maintainer that the Depends is necessary for udisks2 (unlike in 
network-manager where it turned out not to be).


There was some discussion about whether elogind works with udisks2 in 
early 2019 and again in early 2020. On 2020-03-15 Nils draws the 
maintainer's attention to the explicit mention of elogind support in 
udisks upstream changelog.


Later that day, the maintainer closed and archived(!) the bug, for 
reasons they decline to elaborate on.


Mark reopened on 2020-07-02 on the basis that the bug isn't fixed.

Adam sent a ping on 2020-12-31, reminding the maintainer that udisks2 is 
important for a range of desktop software, that the freeze is coming, 
and that udisks2 works with elogind, and asking them again to apply the 
(trivial) patch.


There has been no input from the maintainer of this package for over 9 
months.



Mark tells us that there are not currently any other packages which could be
used with elogind were it not for an incorrect dependency on libpam-systemd,
so I hope we don't need to worry about the broader question any further.


Given the arguments are prone to be very similar, and the issue itself
will unfold in a similar fashion, can we try to have a different
process? One that does not bring so much heat? I hope a very similar
resolution can be had for #923387 - without needing a six-week-long discussion.


I don't think this bug can be resolved by downgrading the Depends: to a 
Recommends:. The maintainer may be able to correct me on that point.


We are getting very close to the freeze; without this fix it will be 
impossible to install a range of desktop software on a bullseye system 
that runs any init system other than systemd.


The maintainer may not like elogind, but udisks supports elogind, and 
the project resolved that technologies like elogind that enabled 
alternative init systems were important to the project.


I have not come to the TC to ask them to overrule the maintainer 
frivolously nor before exploring as many other options as I could. The 
TC is Debian's body for resolving issues of this sort, and the 
maintainer will at least talk to you. Naturally, if you can persuade 
them to fix 923387 in a way that means we can use udisks and elogind 
together in Debian in bullseye I would be delighted. But otherwise, I 
think you must overrule them, and soon enough that they can upload a fix 
so it gets into bullseye.


Regards,

Matthew



Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-15 Thread Gunnar Wolf
Matthew Vernon dijo [Mon, Jan 11, 2021 at 09:07:03PM +]:
> > If you intend the scope of this bug to involve overruling maintainers'
> > decisions in packages other than NM, what other packages/bugs did you
> > have in mind? Is it just udisks2/#923387, or are there more?
> 
> I understand (but I don't think it has been explicitly stated) that the TC
> is going to decline to overrule on the question of init scripts?[0] I'm
> going to beg that question for the rest of this mail, but obviously if I'm
> wrong that will increase the scope somewhat.

I cannot say we will always decline to overrule. But -talking just for
myself, not for the whole TC- overruling a maintainer on
_anything_ is something that I really really really prefer not to
do. I understand the TC is summoned often as a last-resort decision
making body. But forcing a maintainer to do something they are against
in their own package is too harsh -- And demotivating. A maintainer
forced to go against their best decision on an a matter important to
them (otherwise the issue would not get to the TC) is very much more
likely to lose interest in keeping up the maintenance, or even their
participation in the project. 

> Please overrule the maintainer in #923387 so that it is can be used on
> systems with elogind; it has been tested and shown to work thus as well as
> being supported by upstream[1].

As it was mentioned on a previous mail to this thread, this discussion
on including an elogind dependency was done WRT network-manager. An
agreeable solution was brought forward by the maintainer. #923387
(udisks2) was just mentioned in this discussion. Maybe an amicable
solution can be tried before asking the TC outright to overrule the
maintainer?

> Mark tells us that there are not currently any other packages which could be
> used with elogind were it not for an incorrect dependency on libpam-systemd,
> so I hope we don't need to worry about the broader question any further.

Given the arguments are prone to be very similar, and the issue itself
will unfold in a similar fashion, can we try to have a different
process? One that does not bring so much heat? I hope a very similar
resolution can be had for #923387 - without needing a six-week-long discussion.



Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-12 Thread Sean Whitton
Hello,

On Tue 12 Jan 2021 at 01:53PM +02, Wouter Verhelst wrote:

> Maybe talk to debian-policy to come up with some wording to be added to
> either the developer's reference or policy that discourages dropping
> init scripts, but encourages talking to the maintainers of
> orphan-sysvinit-scripts if for whatever reason it ends up being
> necessary?

Once the package has cleared NEW, we should definitely mention it in
Policy; whether we say anything to discourage dropping init scripts is
trickier however.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-12 Thread Wouter Verhelst
On Mon, Jan 11, 2021 at 09:07:03PM +, Matthew Vernon wrote:
> [0] to that end, orphan-sysvinit-scripts is in NEW,

Glad you're taking that route. I had been thinking of other things to
suggest that would make your life easier while allowing maintainers to
drop init scripts if they so desire, but I couldn't really come up with
anything better than that (except for a few very convoluted things that
don't really improve the situation).

> and while I hope your ruling will not result in a bonfire of perfectly
> good init scripts, I hope that maintainers who decide to ditch them
> will let us know so we can add them there

Maybe talk to debian-policy to come up with some wording to be added to
either the developer's reference or policy that discourages dropping
init scripts, but encourages talking to the maintainers of
orphan-sysvinit-scripts if for whatever reason it ends up being
necessary?

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard



Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-11 Thread Matthew Vernon

Hi,

On 10/01/2021 20:03, Simon McVittie wrote:


If you intend the scope of this bug to involve overruling maintainers'
decisions in packages other than NM, what other packages/bugs did you
have in mind? Is it just udisks2/#923387, or are there more?


I understand (but I don't think it has been explicitly stated) that the 
TC is going to decline to overrule on the question of init scripts?[0] 
I'm going to beg that question for the rest of this mail, but obviously 
if I'm wrong that will increase the scope somewhat.


Please overrule the maintainer in #923387 so that it is can be used on 
systems with elogind; it has been tested and shown to work thus as well 
as being supported by upstream[1].


Mark tells us that there are not currently any other packages which 
could be used with elogind were it not for an incorrect dependency on 
libpam-systemd, so I hope we don't need to worry about the broader 
question any further.


Regards,

Matthew

[0] to that end, orphan-sysvinit-scripts is in NEW, and while I hope 
your ruling will not result in a bonfire of perfectly good init scripts, 
I hope that maintainers who decide to ditch them will let us know so we 
can add them there
[1] I've not restated my rationale about how technologies like elogind 
are important to the project per GR etc etc. I can if you like, but I 
don't think that's necessary here




Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-11 Thread Mark Hindley
Simon,

On Sun, Jan 10, 2021 at 08:03:18PM +, Simon McVittie wrote:
> I wouldn't want to give a ruling that would be interpreted as precedent to
> (effectively) overrule multiple maintainer decisions (whether they're
> decisions by a single maintainer in multiple packages, or multiple
> maintainers' decisions in multiple packages) without at least being aware
> of how many packages and decisions we are affecting - similar to the
> principle that when the Policy editors add a new normative requirement,
> they usually want to know how many packages were compliant with the old
> Policy but are considered non-compliant under the new Policy.

[...]

> However, I think we would be reluctant to give a general ruling like that,
> because it would not always be correct. systemd is quite featureful and
> its interface is quite large (if I understand correctly, this is one of
> the major things that people who would prefer a different init system
> dislike about it). Different packages use different subsets of that
> interface, sometimes larger[1] than the subset that can be provided by
> elogind (because elogind closely resembles systemd-logind, and by design
> the other parts of systemd's interface are outside its scope). The extent
> to which the various parts of the interface are required by the dependent
> package (whether they would be Depends, Recommends, Suggests or nothing,
> if they were represented by separate dependencies) also varies.
> 
> dbus-user-session is one concrete example of a package that needs a
> working `systemd --user` instance per uid (a per-uid user-service
> manager), and so will not do what its (informal) specification
> says if it is forced to be installed on non-systemd systems -
> so replacing its libpam-systemd dependency with
> "default-logind | logind" would be incorrect. If that dependency
> was replaced, the replacement would have to include something like
> "libpam-systemd | libpam-start-dbus-daemon-per-uid", where the latter
> doesn't currently exist.

Of course you are quite correct that libpam-systemd provides access to 'systemd
--user' which libpam-elogind does not and can not.

In unstable the list of packages with a hard libpam-systemd dependency is now
quite small. Both dbus-user-session (as you say) and gdm3 require 'systemd
--user' and support for elogind has quite rightly been refused by the
maintainers on that basis. nix-setup-systemd is clearly systemd dependent. 2
packages are empty metapackages[1] with specific purpose that I would not expect
to support elogind. That leaves udisks2 and network-manager as the only
outstanding packages in which elogind support is possible but unavailable.

As in the case of network-manager, I can confirm that my testing of udisks2
shows it works with libpam-elogind without issue.

Obviously Michael is maintainer of both pacakges. In the absence of public
comment or engagement from him I do not want to infer his motives. However, the
end of his submission to the tech-ctte relayed by Elana states

> On Thu, Nov 19, 2020 at 09:04:00PM -0800, Elana Hashman wrote:

[...]
 
> elogind is very difficult to support in its current state (see the
> following bugs: [2] [3] [4] [5]), which is why Michael does not want to
> maintain support for it.

I have already made the point that[2] the bugs he referenced have been addressed
and do not represent a technical reason why elogind should not be supported.

I completely understand that the tech-ctte would not want to make a ruling that
could be over generalised. But I don't think that is what is being asked for
(although Matthew may want to clarify this). This is about securing
implementation of the GR result. If there is a technical reason which prevents a
package working with elogind I completely agree that it would be wrong for it to
make use of the logind virtual packages.

Mark

[1]  progress-linux-base-system and debian-cloud-images-packages

[2]  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975075#224



Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-10 Thread Simon McVittie
On Sat, 02 Jan 2021 at 18:36:23 +, Matthew Vernon wrote:
> While [lowering NM's dependency on libpam-systemd from Depends to
> Recommends] does address the co-installability of network-manager with
> elogind, I would like you to still say something officially about the issue,
> please, since this is not the only affected package.
> 
> As an example, bug 923387 (which Michael is also maintainer of) for udisks2,
> where the dependency must be a Depends not a Recommends (so the workaround
> used for network-manager won't help).

If you intend the scope of this bug to involve overruling maintainers'
decisions in packages other than NM, what other packages/bugs did you
have in mind? Is it just udisks2/#923387, or are there more?

Speaking only for myself as an individual TC member, rather than speaking
for the whole TC, but I suspect others feel similarly:

I wouldn't want to give a ruling that would be interpreted as precedent to
(effectively) overrule multiple maintainer decisions (whether they're
decisions by a single maintainer in multiple packages, or multiple
maintainers' decisions in multiple packages) without at least being aware
of how many packages and decisions we are affecting - similar to the
principle that when the Policy editors add a new normative requirement,
they usually want to know how many packages were compliant with the old
Policy but are considered non-compliant under the new Policy.

>From the original request, it seemed to me that network-manager was
considerably more important to you than other packages with systemd
dependencies, and so you were prioritizing a request to overrule that
particular maintainer decision, so we focused on network-manager. I'm
sorry if that was a misinterpretation.

Perhaps you were hoping we would give you a very general ruling like
"dependencies on libpam-systemd (must|should) always be replaced by
default-logind | logind" that is immediately applicable to all the
other packages you are interested in, and would have an effect similar
to overruling decisions in the other affected packages too, without us
having to specifically vote (with a 3:1 supermajority) to do so.

However, I think we would be reluctant to give a general ruling like that,
because it would not always be correct. systemd is quite featureful and
its interface is quite large (if I understand correctly, this is one of
the major things that people who would prefer a different init system
dislike about it). Different packages use different subsets of that
interface, sometimes larger[1] than the subset that can be provided by
elogind (because elogind closely resembles systemd-logind, and by design
the other parts of systemd's interface are outside its scope). The extent
to which the various parts of the interface are required by the dependent
package (whether they would be Depends, Recommends, Suggests or nothing,
if they were represented by separate dependencies) also varies.

dbus-user-session is one concrete example of a package that needs a
working `systemd --user` instance per uid (a per-uid user-service
manager), and so will not do what its (informal) specification
says if it is forced to be installed on non-systemd systems -
so replacing its libpam-systemd dependency with
"default-logind | logind" would be incorrect. If that dependency
was replaced, the replacement would have to include something like
"libpam-systemd | libpam-start-dbus-daemon-per-uid", where the latter
doesn't currently exist.

smcv