Ansgar <[email protected]> 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 ([email protected]) <https://www.eyrie.org/~eagle/>
