>>>>> "Thomas" == Thomas Goirand <z...@debian.org> writes:
Thomas> On 1/3/20 2:33 AM, Sam Hartman wrote:
>> Secondly, by using systemd-tmpfiles when we can, we gain support for any
>> additional features that are implemented.
Thomas> That's where I don't agree. While it's nice to have such a
declarative
Thomas> system, I don't think it's reasonable to impose the implementation
of
Thomas> any change to systemd to all the other init systems. At some point,
*we*
Thomas> must be able to decide.
This is in fact our disagreement.
The thing is that upstream software is going to start using the new
systemd facilities as they become available.
There's a cost to not having them available in Debian when they are
available.
I think I would handle two cases differently:
1) Enabling the systemd tmpfiles facility for alternate inits:
* use systemd where possible
2) Experimenting with a better tmpfiles interface in hopes of some day
supplanting the systemd interface:
* I think you want to opt into that new interface on a per-package
rather than a per-system level.
Opting in on a per-system level restricts both your ability to innovate
and systemd's ability to innovate.
Holding us back to the LCD of a systemd implementation and some
alternative implementation does not seem to be in the spirit of Proposal
B in my mind. That seems much more consistent with Proposal D and
sticking a stable version of such an interface in policy.
Proposal B is about letting you innovate (for example doing your own
implementation of tmpfiles that you opt into on a per-package basis) and
doing the integration work for alternatives like elogind where you
cannot use the systemd interface.
--Sam
