Hi, On 09.11.2014 13:36, Lucas Nussbaum wrote: > With Choice 3, a package maintainer can decide to support only an init > system that isn't the default if the maintainer considers it a > prerequisite for its proper operation and no patches > or other derived works exist in order to support other init systems > in such a way to render software usable to the same extent.
Yes. That being said, that's a hypothetical point you're making as we (hopefully) all agree to a) appeal on maintainer's responsibility. I cannot imagine anyone endorses a particular init system by deliberately excluding users of other systems unless that would be really necessary for proper operation and thus leaving no choice but doing so. Why do you think we need more regulation for best practices that are known to work in Debian already? We trust developers a lot for a reason. b) it appears that the current "default init system(tm)" is a superset of other available alternatives, with the lowest common multiple being sysvinit style scripts, which are supported by all packages that are providing such start-up scripts, and will continue to do so. In practice choice 3 allows developers to take advantage of special features available by the "default init system(tm)" as a last resort when this is required by the package for proper operation. Yes, choice 3 would also allow the use of "non-default init system(tm)" exclusive features when no alternative way to achieve the same exists with the "default init system(tm)", but really, what could that be, in practice? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D
signature.asc
Description: OpenPGP digital signature
