On 08/10/15 09:48, Mat wrote: > I believe that the two use cases (service start by default or not) could > be satisfied for everyone if we removed startup scripts from service > packages and provided them as separate packages.
This is effectively already done by some packages: for instance, apache2-bin and dnsmasq-base provide the actual daemons, while apache2 and dnsmasq provide what you're calling startup scripts (init scripts, systemd units, etc.) to run them. Removing startup scripts from an existing package breaks upgrades, so for any existing service, the binary package name that matches what we have now must continue to be the one with the startup scripts. For instance, it would be OK to split slapd into slapd-bin (the actual executables and configuration files) and slapd (init scripts, Depends: slapd-bin); but it would not be OK to split it into slapd-systemd (Depends: slapd) and slapd as you suggest, because that way, anyone upgrading the slapd package would lose their startup scripts. A proliferation of tiny packages has a cost, even to people who don't use those packages (it takes up developers' and archive administrators' time, and it makes everyone's Packages files larger, taking more bandwidth/disk/memory/CPU for upgrades), so that split should only be done where there's actually some reason to do it. "A reasonably popular package needs to run this service in its build-time regression tests" might be one reason to justify it - for instance, libsoup (a GNOME-related HTTP library) uses apache2-bin for its regression tests. However, another solution to testing is to use autopkgtest to test installed packages instead of doing build-time testing, preferably in a virtual machine created for the purpose and discarded afterwards (adt-virt-qemu); for autopkgtest in a VM, just using the full service package isn't actually a problem. > As a side-effect, this approach would allow creating packages such as > "slapd-sysvinit", "slapd-runit" or "slapd-s6" if we wanted to support > multiple init and/or service supervisor systems. I think having a binary package per init/supervisor system has a cost that exceeds its benefit - it results in a lot of tiny packages each containing a couple of small text files. dnsmasq contains startup scripts for both systemd and sysvinit, and each init system will use the most capable dialect of startup scripts that it understands, ignoring the others. I think that's a better model. S