[debhelper-devel] Bug#887900: dh_installsystemd does not properly handle aliased services

Felipe Sateler fsateler at debian.org
Wed Jan 24 22:21:26 UTC 2018


Hi,

On Wed, Jan 24, 2018 at 5:44 PM, Michael Biebl <biebl at debian.org> wrote:
>
> Am 24.01.2018 um 21:32 schrieb Niels Thykier:
> > On Sun, 21 Jan 2018 15:44:05 +0100 Michael Biebl <biebl at debian.org> wrote:
> >> Package: debhelper
> >> Version: 11.1.3
> >> Severity: normal
> >>
> >> I use the following in network-manager:
> >>
> >> override_dh_systemd_start:
> >>        dh_link -pnetwork-manager \
> >>               lib/systemd/system/NetworkManager.service \
> >>               lib/systemd/system/network-manager.service
> >>        dh_systemd_start -pnetwork-manager --no-also NetworkManager.service
> >>
> >> The background is, that traditionally, the Debian SysV init script is
> >> called /etc/init.d/network-manager and the upstream systemd service is
> >> named NetworkManager.service
> >>
> >> I thus created the symlink which told dh_systemd_start to not generate
> >> start code for NetworkManager.service (using deb-systemd-invoke) but
> >> leave this up to invoke-rc.d network-manager
> >>
> >> It seems this no longer works with dh_installsystemd.
> >>
> >> [...]
> > Hi Felipe,
> >
> > What is your take on this bug?
>
> I assume the answer will be basically the same as for
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887904#10
>
> I think we should invert the logic and stop letting
> dh_installinit/invoke-rc.d handle services which have a native systemd
> .service file.


Yes, I agree with this. The current default in debian is systemd, and
systemd units offer more expresiveness than sysvinit allows (eg, one
could have a socket enabled and active but have the actual daemon wait
for socket activation). Therefore it makes sense to only use the
dh_installinit snippet as a fallback when systemd is not pid1 or when
there is no native unit.

I've been meaning to write a patch for this but unfortunately I
haven't found time to do it.

However, this is a (possibly quite noticeable) change in behavior, and
thus it might make sense to bump this change into compat 12. I'm not
sure I would consider compat 11 systemd+sysvinit broken enough to
warrant introducing such a change.


> Maybe this could be as simple as letting dh_installinit in compat 11
> generate code which wraps the invoke-rc.d call like this:
>
> > if ! [ -d /run/systemd/system ] || ! [ -e /lib/sytemd/system/foo.service ] ; then
> >       invoke-rc.d foo $_dh_action || exit 1
> > fi
>

Something like this, yes. But this seems a bit simplistic (would we
want to check /etc, /usr/lib, /usr/local/lib and /run ?)

Niels, what do you think about having dh_installsystemd populate a
variable (in the maintscripts) with the acted upon scripts, so the
dh_installinit-generated maintscripts can use that to determine
whether to act or not?

-- 

Saludos,
Felipe Sateler




More information about the debhelper-devel mailing list