Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
>>>>> "Matthew" == Matthew Vernon <matthew@debian.org> writes:
Matthew> On 15/12/2020 22:07, Sam Hartman wrote:
>>> However, Debian remains an environment where developers and
>>> users can explore and develop alternate init systems and
>>> alternatives to systemd features. Those interested in exploring
>>> such alternatives need to provide the necessary development and
>>> packaging resources to do that work. Technologies such as
>>> elogind that facilitate exploring alternatives while running
>>> software that depends on some systemd interfaces remain
>>> important to Debian. It is important that the project support
>>> the efforts of developers working on such technologies where
>>> there is overlap between these technologies and the rest of the
>>> project, for example by reviewing patches and participating in
>>> discussions in a timely manner.
>>
>> We did not say in that GR that we were interested in supporting
>> ongoing development of sysvinit.
Matthew> I find it surprising that, in a TC bug about (inter alia)
Matthew> whether a dependency on libpam-systemd should be changed to
Matthew> default-logind | logind i.e. to facilitate use of elogind
Matthew> you appear to be saying that a GR text that talks about the
Matthew> importance of "technologies such as elogind" should be
Matthew> interpreted as meaning in effect that actually it isn't all
Matthew> that important and network-manager should continue to have
Matthew> effectively a systemd-only dependency.
I'd like to be heard differently.
I think that we should either decide that
1) NetworkManager should support elogind
or
2) That we haven't seen enough development of alternatives to systemd
and the project consensus on the GR has changed.
Matthew> Not is it straightforwardly clear that "alternative init
Matthew> systems" should in fact be interpreted to mean "alternative
Matthew> init systems (but not sysvinit)".
I'd like to be heard differently on this point too.
I think that to the extent that people are doing things like adding
support for service units, looking at ways of solving problems that
motivated systemd in non systemd ways in the sysvinit ecosystem, that
clearly counts as development of alternative init systems in the scope
of the GR.
I think that maintaining sysvinit for stable releases so that users can
use it does not count as development of alternate init systems.
I understand that several people in the project want to do that work.
I'm not speaking against that work here, but I don't think you can use
the GR as support for that work.
Matthew> Nor is this a case of someone demanding that the
Matthew> network-manager maintainer provide a sysvinit script nor
Matthew> fix the bugs in an existing-but-broken one.
Understood.
I did suggest to Mark that he use that argument in arguing for
maintaining the init script.
As I mentioned policy process was not able to come to consensus on when
to remove existing init scripts.
--Sam
Reply to: