>>>>> "Santiago" == Santiago Vila <sanv...@debian.org> writes:
Santiago> El 10/9/23 a las 4:09, Russ Allbery escribió:
>> I therefore would like to propose a first: I think Policy should
>> simply say that any package that provides a system service should
>> use debhelper and rely on dh_installsystemd to put the
>> appropriate commands in its maintainer scripts. (We can then
>> discuss whether we should do the same for init scripts and
>> dh_installinit, although its stanzas are simpler.)
Santiago> Hello. I don't like this approach, and I believe we are
Santiago> mixing two different things here. One of them is our
Santiago> ability (or lack thereof) of policy to catch up with real
Santiago> development done elsewhere. Another one is the fact that
Santiago> policy does not mandate any given implementation.
The question in my mind is whether it is valuable to support multiple
implementations, and I think the answer is no.
In the past, there was not a preference for using debhelper. So, back
then, we did need to support multiple implementations of debian/rules,
and we needed to specify the things debhelper did.
Having a specified interface like policy is expensive. I know; I've
spent a good chunk of my life working on various protocols and
standards.
Having specified interfaces brings value when you need multiple
implementations and in a few other cases, like where you need to plan
for certain forms of extensibility or isolation.
There's a part of this where we do need an interface. We will have
multiple packages wanting their debian/rules to install systemd units.
So, we do need to at least say or imply that if you stick systemd units
in the right place and call dh_installsystemd, then your systemd units
will be properly handled.
But today, we have a policy preference for using debhelper. We do not
need multiple implementations of debhelper. There does sort of need to
be an interface between debhelper and systemd if for no other reason
than to allow for systemd to change and to control which details are
hard-coded in maintainer scripts. But if we agree that we do not need
multiple implementations of debhelper, the policy team does not need to
be part of defining that interface. We can be more efficient by not
being involved in that process. Also, we can do a better job of
focusing on the interface that the project does care about (how to tell
debhelper to install your systemd units) and not confuse people with the
details between debhelper and systemd.
Also, by explicitly acknowledging that the deb-systemd-helper and
deb-systemd-invoke interfaces are effectively between debhelper and
systemd, those interfaces can be simpler because they do not need to
allow for multiple implementations of debhelper or systemd.
In effect by making this decision, we are strengthening our preference
for saying packages should use debhelper. For a significant class of
packages (those with service units) there really will be no easy
alternative. And if we go down that route, over time, we will probably
prefer debhelper more and more, and it will be less possible to generate
a policy-compliant package that does not use debhelper.
I think that's desirable.
I think we can still find ways to experiment with new more declarative
ways of handling package building. But I think that having more
uniformity in the cases where we have a single solution that has broad
support will make things easier for everyone.
Put another way, having multiple implementations is often very expensive
in terms of interface complexity, testing complexity, and especially
complexity that developers need to deal with.
In this instance, I do not think that cost is justified.
--Sam
signature.asc
Description: PGP signature
