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
