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

Re: REISSUED CfV: General Resolution: Init system coupling



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

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: