On 08/10/15 12:13, Simon McVittie wrote: > 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.
In order to not break upgrades, in this example the slapd package itself could be turned into a transitional package (Depends: slapd-bin, slapd-systemd). > 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. I understand that developer's time is a scarce resource. >> 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. I for one would highly value such benefits. I can't say about the cost, though. > 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. Yes, this works too, and it looks like a good middle ground between high flexibility and keeping the number of tiny packages low. -- Mat <m...@parad0x.org>
signature.asc
Description: OpenPGP digital signature