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

[Niels Thykier]

Felipe Sateler:
> Hi,
> 

Hi :)

> On Wed, Jan 24, 2018 at 5:44 PM, Michael Biebl <biebl at debian.org> wrote:
>>
>> [...]
>>
>> 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.
> 

Ok.  So separating the systemd and installinit snippets would solve both
bugs?

> 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.
> 

I think we should do it in a separate compat bump.  With where things
are headed, I think I got enough changes to do a compat 12 as well in
buster.

> 
>> 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 ?)
> 

Can we just have " [ -d /run/systemd/system ] " be the gate both ways?
Is there any case, where that would do the wrong thing?

I.e.

# dh_installinit inserts:
  if [ ! -d /run/systemd/system ] && ... ; then
    ...
  fi

# dh_installsystem inserts:
  if [ -d /run/systemd/system ] && ... ; then
    ...
  fi

This means that dh_installinit's snippet is run when we are not running
systemd and dh_installsystemd's snippet is run when we are running
systemd.  It is simple to write and is simple to explain, so if that
does the right thing, then it feels like the right approach.

The above will need some testing with lintian to ensure that we do not
get errors/warnings because lintian makes assumptions about shell
patterns in maintscripts.

> 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?
> 

The order of snippets are fragile.  Particular, *rm scripts get reverse
order of *inst scripts.  I would prefer that the (combined) snippets
(from a single handler) are stand-alone.  Then we can trivially reason
about what a helper produces and what it snippets do.
  Snippets are complicated enough already with our 20 different ways
they can be called while they always have to DTRT.  Adding
dependencies/relations between snippet from different helpers is an
additional layer of complexity that will just haunt us later.

Thanks,
~Niels