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

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

On Sun, 27 Dec 2020 15:39:47 -0700, Sean Whitton wrote:

> On Sun 27 Dec 2020 at 07:26PM +02, Wouter Verhelst wrote:
> > My reasoning is that init scripts are the end goal, and that elogind is
> > just a symptom of that end goal, and that therefore talking about
> > elogind in isolation serves no purpose.
> The GR specifically mentions elogind and not init scripts.

"Technologies /such as/ elogind …" (emph. mine) shows to me that this
is meant as an example, as a "demonstration", and not as an
exhaustive list [0]. So neither is elogind "special" nor is it the
only relevant piece of software to consider supporting. [1]

What surprises me in this discussion: My very broad summary of the GR
result was "systemd is the top priority, other init systems are
supported on a best-effort basis", and now I'm reading statements
which sound to me like "looking into new/future/niche init systems is
ok-ish but we never meant sysvinit when we said 'alternate init
systems'", and that's either a misunderstanding of some mails on my
side or an interpretation I find implausible to draw from the text of
the winning GR option.


[0] in German (and probably Roman) legal terms, "demonstrativ" vs.
"taxativ", cf. https://de.wikipedia.org/wiki/Enumerationsprinzip and

[1] I also think that this is an example of why naming one specific
software in a normative text is not such a good idea.

 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Carole King: Smackwater Jack

Attachment: signature.asc
Description: Digital Signature

Reply to: