Re: How to handle daemon-not-running bugs of debhelper compat level 11?

[Niels Thykier <niels@thykier.net>]

Michael Biebl:
> Am 30.04.19 um 17:26 schrieb Michael Biebl:
>> Am 29.04.19 um 21:53 schrieb Niels Thykier:
> 
>>> override_dh_installinit:
>>> 	DH_COMPAT=12 dh_installinit ...
>>>
>>> override_dh_installsystemd:
>>> 	DH_COMPAT=12 dh_installsystemd ...
>>>
>>> Note the exact runes needed depend on your existing compat level and
>>> package; the above runes are geared towards compat 11 but are untested.
>>>  For compat 10 and earlier you want a similar but slightly different
>>> approach.
>>>
>>> I believe that is the (general) route/path of "least evil/problematic"
>>> for buster (without having looked at the concrete packaging at all).
>>

For reference, I forgot that the packages must have a

Pre-Depends: ${misc:Pre-Depends}

(or an explicit pre dependency on init-system-helpers (>= 1.54~), but
the former is strongly preferred).

>> I picked a package from list.txt at random: uptimed
>> I verified that a "apt install uptimed; apt remove uptimed; apt install
>> uptimed" sequence results in a non-running uptimed.service.
>>
>> I then followed the hints from Niels and tried the attached patch.
>> It seems to fix the issue at hand.
>>

Thanks for confirming. :)

>>
>> I'd be interested to know, how the release team would like to this issue
>> handled.  While I did spot a few false positives when glancing over the
>> list (e.g. packages which use --no-start, so are not affected), I would
>> expect the majority of packages to be affected.
>>
>> I can offer to do a MBF if the release team thinks this issue is
>> important enough to be fixed for buster.
> 
> If the release teams thinks that this should be fixed for buster, I
> wonder if we shouldn't consider a second approach: Updating debhelper to
> use compat mode 12 behaviour for dh_installinit/dh_installsystemd if
> compat mode is set to 11.
> This would avoid a lot of churn. If we basically update all packages to
> use compat mode 12 behaviour explicitly, we might just as well do that
> change in a single package.
> 
> Regards,
> Michael
> 

We would still have to issue binNMUs and we can only do this for
arch:any packages with a "Pre-Depends: ${misc:Pre-Depends}" already
(otherwise, it will cause upgrade issues - or for arch:all, the binNMU
will be rejected).

Do you have an estimate of how many packages can be binNMUed vs. how
many will require a manual upload regardless?

Thanks,
~Niels