Re: [draft] Draft text on Init Systems GR
Ansgar <ansgar@43-1.org> writes:
> 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.)
Yes, I agree that the lack of resources on the Policy side is a downside
to any of the options that rely on the Policy process. It's a downside
risk that I'm willing to take, and I think there are motivated people who
want to adopt those interfaces and therefore would be willing to write
Policy text to do so and that this sort of GR would unblock that work, but
I could be wrong.
> 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'm not sure why you think this is the case. Could you explain more about
what upstream package blocking you expect? Upstreams that only support
systemd don't need to wait for a Policy specification of the facilities
they rely on under Ian's proposal; the Policy discussion is only about
general adoption of the facility to replace existing Debian-specific
approaches. Ian's proposal only requires that the maintainers accept
patches to port systemd-only software to other init systems once those
patches have been written, and asks that Policy not require systemd-only
services be used by packages that aren't otherwise systemd-only without
this specification and transition period.
> 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 wouldn't expect us to pick unit files as one of the interfaces to
document in the near future. We would start with the simpler features,
such as specific features within unit files (like DynamicUser).
Most unit file features are not mandatory for the program to run and hence
probably wouldn't need to be documented separately in Policy because they
don't constitute a required interface. We would need to document things
like the socket activation protocol or tmpfiles.d or sysusers.d.
> 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".
That's a very good point.
If something is popular and people want to use it, saying that it has no
value is pretty obviously wrong. Anything that people want to use has
some sort of value.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: