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

Re: [draft] Draft text on Init Systems GR



Ansgar <ansgar@43-1.org> 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.  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.)

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

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

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>


Reply to: