Re: init script, installed but not activated
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
Reply to: