[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: init script, installed but not activated



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 <mat@parad0x.org>

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: