Colin Watson writes ("Bug#727708: init system coupling etc."):
> Would it improve things if we added an informative paragraph such as
> this? (I'm not necessarily asking whether it would lead you to rank
> this option higher, just whether it makes the intent clearer.)
>
> This policy is intended for the current situation where most services
> can still easily include support for multiple init systems by means
> such as shipping a sysvinit script. If this changes then we expect to
> revise this policy or ask the policy editors to do so.
I guess open to the idea of a clarification along these lines, but I
would want to ensure that this was limited to the question of service
startup. Otherwise we will be faced with claims that the new foobard
service provided by only one init system is now absolutely mandatory
for subsystem wombat and this paragraph justifies revisiting the
situation.
Frankly I find it difficult to imagine a situation where it is
impractical, or even an unacceptable amount of work, to provide
service startup for multiple init systems.
> I understand that there is a theoretical ambiguity here, but I'm not
> sure how to tighten it up and I'm not keen on spending time doing so
> since I think it will remain theoretical.
Quite.
> > I think what you're trying to say, from the above, is:
> >
> > All software that needs init system configuration must include
> > sysvinit scripts. Software may not require any functionality from the
> > init system that cannot be provided via init scripts, although
> > degraded operation is tolerable. The exceptions to this are as
> > follows:
>
> I would be fine with this, perhaps with s/require/have a hard
> requirement of/ for the sake of emphasis, and s/via init scripts/via
> init scripts or other similar compatibility mechanisms/. But it's
> really Ian's proposal; Ian, what do you think?
I think it's better not to get into implementation details.
If someone comes up with a compatibility approach that doesn't involve
packages actually shipping sysvinit scripts, we wouldn't want to rule
it out. Eg, perhaps the sysvinit scripts are autogenerated at
package install time; or perhaps the package is started by a
supervisor daemon which itself has a sysvinit script, but the package
itself only has configuration for said supervisor (and perhaps no
other init system config at all).
I have some opinions about the best approaches to cross-init-system
compatibility but I wouldn't want the TC to prevent policy from
evolving if experience shows those opinion to be wrong, or even if
simply the people doing the work decide to do things differently.
So I agree that _at the moment_ the TC wording implies that everyone
must ship a sysvinit script. But with future advances or changes
that may cease to be true.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
