On Wed, Nov 20, 2019 at 7:41 AM Ian Jackson <ijack...@chiark.greenend.org.uk>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> (Kurt, you can skip to "FAO KURT".)
>
> Dmitry Bogatov writes ("Proposal: Init Diversity"):
> > Here I formally propose following option, withdrawing any previous
> > versions.
> ...
> > Being able to run Debian systems with init systems other than
> > systemd continues to be value for the project. Package MUST work
> > with pid1 != systemd, unless it was designed by upstream to work
> > exclusively with systemd and no support for running without
> > systemd is available.
> >
> > Software that uses systemd features non-conditionally should be
> > considered as designed to work exclusively with systemd, but
> > software that does just do not provide init.d should not. In
> > case of doubt, explicit statement of upstream is definitive.
>
> I have been having an email discussion with Dmitry about this. I find
> this final paragraph unsatisfactory because it seems like it could
> contradict the first part. As I wrote to Dmitry:
>
> So, for example, suppose I find a daemon that unconditionally
> expects the systemd daemon startup protocol. I write a patch to
> make it able to work differently, with perhaps a command line option
> or something. I submit it upstream, who say "no we are not
> interested, this is designed to work exclusively with systemd". Am
> I now to give up ? Debian need not take my patch.
>
> Dmitry replied that this was not his intent, and explained his intent
> to me. He said he would welcome a proposed amendment. I don't have
> permission to quote his email, but I think I can capture his intent.
>
> For now, I propose the following amendment: <=== FAO KURT
>
> Delete the 2nd paragraph of Dmitry's proposal and replace with:
>
> Software is not to be considered to be designed by upstream to
> work exclusively with systemd, merely because upstream do not
> provide, and/or will not accept, an init script.
>
> I think the effect of this is:
>
> * For software that merely needs an init script writing, an init
> script MUST be provided (by the Debian maintainer, if necessary).
>
> * For software that needs other patches writing, it is up to the
> community to write patches for non-systemd support. The maintainer
> does not need to write them but MUST accept them if they are
> provided, because then "support for running with systemd is
> available".
>
> * Software that is inextricably tied to systemd is permitted,
> even though it only works with systemd as pid 1.
>
> Dmitry's wording is less specific than mine about what happens if
> non-systemd support patches are themselves RC-buggy but I think the
> effect is the same. It would be unreasonable to say that "support for
> running without system is available" if the "support" is RC-buggy.
>
> I would appreciate it if others here would comment on my wording and
> maybe help improve it. Dmitry's email latency means that he won't be
> able to participate in the drafting as fully as ideal, so I would like
> to make sure that he is offered the best possible wording.
>
> For the avoidance of doubt, I am not trying to hijack Dmitry's
> authority over his text. Please do not second my amendment. I am
> hoping Dmitry will accept it (or some other similar improvement). If
> Dmitry does not accept it I will withdraw it.
>
For the record, I plan to second Dmitriy's amendment once he has finalized
it..
-Brian
-----BEGIN PGP MESSAGE-----
owEBpQJa/ZANAwAIAcD4hkzaPQNYActeYgBd1a+wRm9yIHRoZSByZWNvcmQsIEkg
cGxhbiB0byBzZWNvbmQgRG1pdHJpeSdzIGFtZW5kbWVudCBvbmNlIGhlIGhhcyBm
aW5hbGl6ZWQgaXQuLgoKLUJyaWFuCokCMwQAAQgAHRYhBK8RPdDsSYzYhL3LNsD4
hkzaPQNYBQJd1a+1AAoJEMD4hkzaPQNY/NUP/0XlgSxFlIKFBGoqKzfViyfaJGLW
OABbOisyAbl1G/ZlR4wIhXZkZu8exi//2bJ4CJyKua9YQ1aO15aSsiYk55p9xOIR
XiVpI9JRIp5wFrpfSQNzKfku4aGRsZUxaafkylT6bOST/73gQxIzXF2TfX93WDVl
/mD5mwlK893kzvGgo2NZ60e7puqgRuQH7gwX/u0RQFA26lDc1k9+O5lR1ngOkvbk
8izHbQDeoGOVtQPNmh82Xk5KLYqbl5tLfhDPbMmf1qFun1S4WncZJqBzLcyPKzRs
0IzQwPfjk5sMyfKGIB/ebNxXFXc1fjoKa2eaKVxXKf5pYJj99DOKRnwkKZ/sH+sa
5m9Ma8ZU5+7EOFPPgNBJmiini7gqCCHutzHvRrAutzdiD+POlcvuqkxHcJB9lwNO
lcAOtHDhJhr8lF5Pn/9Nn9COwkCc/fZMscmJnC/61yf7UfG3SweGiLwXNjserDlm
dhw1g9gttg0zCzP+mliV70Rrg4EJzifBomjJUpQUE5hVOzRUGN/fOCnEDEZa/Tlf
sHC4ZY6fvOfDGpHkFOoINfa5z6gqGKHXA4PlA1EUYpJlNniSMMcbdbwi4Sl2oIFf
qMZx638kPiscsMCKiQLHPXK89GdDFoqgdGEYOzR+X77NZOZJa/nN8lRkd9YtBMTD
CysseEuYth9rYJuL
=sx3I
-----END PGP MESSAGE-----
> Ian.
> -----BEGIN PGP SIGNATURE-----
>
> iQFUBAEBCAA+FiEEVZrkbC1rbTJl58uh4+M5I0i1DTkFAl3VNC8gHGlqYWNrc29u
> QGNoaWFyay5ncmVlbmVuZC5vcmcudWsACgkQ4+M5I0i1DTn3zAf/fy8Kdp1pWDmh
> vQD9cH+bAQpBrsUtzk/vhEdMD+I5D3X6XatxgTgJHQhbdhKXBFSKAEzWoqhAJvTy
> e+XoPQN+ftzMlg796YVioGiKntD8iw0gb693mDtrx80WcDGM6IUhe4WtDR4L9E2R
> 1vEU3qpON+W9GmnkE2gMINs8h1fpsIwFWiaGyGtGInoSraHtwZVjME7Sn8QXbhdr
> 6w4J01y52a2e+GQbCYCjAq7zDV5UD/QbKCrJHn5+jQQh0tH4g7+IN6uZc3UXP+3d
> nl+T1nfzAMKS2GtvlgeSJHVFBG96Q/q41nDXSr4Re90O5qgeWo3CF7nntee08GEP
> Kj+YB8DPuw==
> =fWly
> -----END PGP SIGNATURE-----
>
