[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Matthew Vernon <matthew@debian.org> 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 (rra@debian.org)              <https://www.eyrie.org/~eagle/>


Reply to: