Response to active removal of initscripts

[Lorenzo]

On 02/07/20 18:11, Joost van Baal-Ilić wrote:
> Hi Mark, Thanks a lot for reporting these bugs! But: I read
> "Maintainers use their normal procedures for deciding which patches to
> include." @ https://www.debian.org/vote/2019/vote_002#textb I'm afraid
> I don't have any concrete proposal on what to do now :( Bye, Joost On
> Thu, Jul 02, 2020 at 04:49:09PM +0100, Mark Hindley wrote:

So I am the only one who read

"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."

and

"Debian is committed to working with derivatives that make different
choices about init systems. As with all our interactions with
downstreams, the relevant maintainers will work with the downstreams to
figure out which changes it makes sense to fold into Debian and which
changes remain purely in the derivative."

?

My understanding is that they can remove the initscript ( "use their
normal procedure ..") but when it comes to a facility like elogind (or
opentmpfiles, opensysusers and systemctl ) they need to cooperate with
downstream like Devuan, the can't just dowgrade the severity to
whishlist and close bugs like that.

The problem is that the wording is vague, so IMHO we need to escalate
this, starting with editing the policy [1] in a way that (something like
the following)

[2]"each package that depends on a systemd facility must depend on a
specific virtual facility and not on systemd, when a suitable
alternative provider of such facility exists (is packaged) in Debian."

the above will clearly lead to an escalation to the TC, anyway better
now than close to the freeze

Lorenzo


[1] the part of "you need to provide a systemd unit and you can remove
any alternative init" was already proposed but there is no part in
policy to substantiate how the cooperation with downstream is going to
be, expecially with regards of technology like elogind that are critical
to explore alternatives.

[2] i'm not a native english speaker/writer so, to clarify what i mean:

* the facility must exists (logind, tmpfiles,sysusers, systemctl)

* systemd can provide the above facilities

* an alternative provider of a facility can provide its facility

* packages that wants to depend on a systemd faility must use the
virtual facility if exists:

   not use systemd, not use 'systemd | virtual-facility' or any other
variation (apt resolver can't handle

   the 'dep1 | dep2' very well IMHO, so let's try to get rid of that)

* yes, plain depends on systemd when an alternative facility exists
should be an RC bug, RC in a way that prevents the release in stable,
simply because there is a small group of DD that are hostile and
uncooperative in a way that blocks us and we are already plenty of
examples of that.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9A8E678DDE03DEB8.asc
Type: application/pgp-keys
Size: 6279 bytes
Desc: not available
URL: <http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/attachments/20200703/a909a3f2/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/attachments/20200703/a909a3f2/attachment.sig>