Re: Proposal: Init Diversity

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

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

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