>>>>> "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