Hmm - imho the package should not be able to break apt. Thats my main point. Ok, starting the service fails, it might be a problem in systemd or in the generated service. Different thing - so even if the start fail, it should not break the installation.
> # Automatically added by dh_systemd_enable/10.10.5 > # This will only remove masks created by d-s-h on package removal. > deb-systemd-helper unmask 'redis-server.service' >/dev/null || true > > # was-enabled defaults to true, so new installations run enable. > if deb-systemd-helper --quiet was-enabled 'redis-server.service'; then > # Enables the unit on first installation, creates new > # symlinks on upgrades if the unit file has changed. > deb-systemd-helper enable 'redis-server.service' >/dev/null || > true > else > # Update the statefile to add new symlinks (if any), which > need to be > # cleaned up on purge. Also remove old symlinks. > deb-systemd-helper update-state 'redis-server.service' > >/dev/null || true > fi > # End automatically added section > # Automatically added by dh_installinit/10.10.5 > if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ]; then > if [ -x "/etc/init.d/redis-server" ]; then > update-rc.d redis-server defaults >/dev/null > if [ -n "$2" ]; then > _dh_action=restart > else > _dh_action=start > fi > invoke-rc.d redis-server $_dh_action || exit $? > fi > fi The part added by dh_systemd_enable is ok and should not fail. But the line: > invoke-rc.d redis-server $_dh_action || exit $? added by dh_installinit look fugly - exit with error no is not the outcome that the very most people would expect or prefer - so what do you suggest? Filing a bug against dh? Cheers Alf On 05.11.2017 22:14, Chris Lamb wrote: > Hi Alf, > > Thanks for your reply. > >> * redis-server isn't installable, it should be >> * the start in postinst fails - for what reasons ever, nothing of any >> interest at this point - but that make the package uninstallable > The reason is surely highly relevant. ie. it is due to a bug in lxc > and/or systemd (or something else entirely), not Redis, and thus it > should be reassigned elsewhere? > > You can then use the "affects" tag in the BTS so that it appears in > the Redis bug list, but that's simply to help direct others and > prevent potential duplicates. > > > Regards, >
