Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages
Matthew Vernon dijo [Mon, Jan 11, 2021 at 09:07:03PM +0000]:
> > 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.
Reply to: