Re: [draft] Draft text on Init Systems GR
Russ Allbery writes:
> Ansgar writes:
>> On Thu, 2019-11-14 at 18:29 -0800, Russ Allbery wrote:
>>> As with Dmitry's proposal, I'm not seconding this because it's not my
>>> own first choice, but I would vote this above further discussion and
>>> I'm satisfied that it's clear about the Policy implications.
>
>> Do you think it is realistic/practical to require documentation for
>> interfaces such as logind to be included into Policy (without references
>> to external documents) before they are allowed to be used in Debian by
>> any packages?
>
> I was assuming that logind was out of scope (as was udev) because both
> have already been adopted by Debian, so this isn't the same situation that
> Ian's proposal is describing. The remaining facilities that I was
> thinking about are much more straightforward to describe.
>
> You raise a good point that this may be challenging if another interface
> of the complexity of logind or udev is added and Debian wants to adopt it.
> I'm willing to take that risk, but it's a risk.
It doesn't have to have the same complexity as logind or udev. Keep in
mind that Policy doesn't even document init scripts properly: in
particular LSB comment headers and such are also missing. We weren't
able to document that in Policy for a looooong time and other Policy
requirements are very unclear as a consequence. (Or multiarch for
another example.)
Given that history, I'm not sure we would be able to introduce any new
facilities via Policy in a reasonable amount of time and don't think it
is reasonable to totally block usage before this has happened (plus
additional 12 months).
Note that this would also block updating upstream packages to new
releases, possibly delaying development for a long time. I don't think
we need much slower development cycles.
> I expect if that happened
> we would likely treat it similarly to the FHS and incorporate a copy of
> the relevant specification into the debian-policy package rather than
> trying to rewrite it. (This achieves my understanding of what Ian is
> after, namely that the specification itself not be a moving target from
> systemd upstream but go through the Policy change process when it's
> updated.)
So submit a copy of all systemd man pages to Policy and update them
every few months? (To document unit files without external references.)
I honestly don't see much advantage over just referring to external
documentation and possibly list exceptions in Policy (should they
exist), i.e. follow upstream changes by default, clarify deviations if
necessary.
(Unrelated: should LSB be included in Policy? We possibly require some
parts of that, such as the init script parts...)
>> What do you think should happen when logind gains a new feature (or "new
>> systemd subfeatures of questionable value" as some would say)? That
>> would seem to (re)trigger the requirement to incorporate logind into
>> Policy (if agreement can be reached) and wait up to a year before
>> using it...
>
> I'm assuming that's not the case, but yes, maybe that's worth clarifying.
> I'm not particularly eager to try to maintain a specification of logind
> inside Policy.
Me neither. I very much prefer to refer to external documentation
(Don't Repeat Yourself).
(I've also seen LSB documentation for library interfaces. Please let's
not go anywhere in that direction.)
>> Would calling sysvinit or subfeatures like elogind to be "of
>> questionable value" still be acceptable? :)
>
> I think calling sysvinit of questionable value is clearly factually
> incorrect. It performs a necessary task in a UNIX system, so it clearly
> has value. The debate is over its *relative merits*, not it's value. I'd
> therefore rather people not make statements like that because I think
> they're sloppy and seem more designed to indicate tribal affiliation or
> rile people up than to communicate information.
>
> I think calling specific features of *any* piece of software "of
> questionable value" has to be within bounds for a technical
> discussion.
I think pretty much any feature has value. The debate should be over
its relative merits, sadly some other people find it necessary to
preemptively call unspecific features that some might want to use later
(and thus clearly would see value in them) to be "of questionable
value".
Ansgar
Reply to: