Hi,
On 6/28/23 22:42, Holger Levsen wrote:
I'm not sure Debian Policy is the best place to document this, because Debian
Policy
documents what packages *must* comply with, while legacy initscripts are a thing
of the past which still are permitted (and liked & prefered by some), so *maybe*
src:dev-ref would be a better place for documenting those best practices?
According to Policy as currently published, systemd units are
encouraged, and init scripts are mandatory.
We have GR and TC decisions that say otherwise, but the proponents of
the systemd migration have, to this day, not done their homework, to a
large degree because there are rather few people doing the actual
work[1], and, as Luca indicated, that happens largely in their spare
time after a full workday working on the same software.
This is not sustainable, and it cannot be made sustainable by incurring
more technical debt[2], and we will need to address this at a project
level soon.
A large part of the opposition to systemd is that this situation was
predict(able|ed), yet people kept forging ahead anyway. That's the
thing: few people want init scripts. I don't want init scripts either.
What I want is an init system that can be maintained inside a community
project like Debian without burning out people and endangering the long
term viability of the project.
That is where systemd fails us as a community project, because the
environment in which most of development is happening is not hospitable
to community building efforts, and the complexity of the project
constitutes a high barrier to entry, which acts as a further selection
filter for contributors.
This is why we are stretched so thin here: anyone we wanted to onboard
into systemd package management we'd have to properly train for this
role, we have no process for that because we didn't need one before, and
everyone is aware that it will be a thankless job because a large part
of it will be taking decisions made upstream into the project.
I don't yet see a clear path out of this. The only thing that is obvious
to me is that this is not a technical problem[3].
Simon
[1] a distinct group from "proponents"
[2] and pointing out that we are incurring technical debt is additional
stress and makes the people trying to come up with solutions feel
unappreciated.
[3] apart from the existing technical debt
