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