Thanks Simon for the clarification.
On 6/25/18 1:04 AM, Simon McVittie wrote:
> On Sun, 24 Jun 2018 at 17:05:54 -0600, Daniele Nicolodi wrote:
>> Packages that will use dh_installsystemduser will have maintainer
>> scripts that will depend on the next relese of init-system-helpers.
>> dh_installsystemduser will then inject a versioned dependency using the
>> ${misc:Depends} substitution in debian/control.
>>
>> Is that enough to ensure that postinst and postrm maintainer scripts are
>> run with the right version of init-system-helpers available? Should I
>> be using Pre-Depends instead?
>
> https://www.debian.org/doc/debian-policy/#summary-of-ways-maintainer-scripts-are-called
I read that, but I was not sure if my interpretation was right. Indeed,
my conclusions were different.
> For the postinst, you can rely on the updated init-system-helpers being
> at least unpacked (which should be enough, because i-s-h is Essential,
> so it's required to provide its core functionality while merely unpacked
> and not yet configured).
>
> The difference for Pre-Depends is that it would give you the ability to
> assume that i-s-h has been configured (fully installed) before your
> postinst runs. I don't think you need that here.
>
> In the postrm, you can't normally rely on having your package's
> dependencies still installed, but init-system-helpers is Essential so
> it should still be there, and we don't officially support downgrades so
> i-s-h should still be at least the required version.
Only tangentially related: does that mean that we can drop the checks
for the presence of deb-systemd-helper in the postrm maintainer scripts
injected by dh_installsystemd (for example [1]) and simplify them a bit?
> Most packages do the more involved parts of their removal in the prerm.
> Is that feasible here?
I'm not sure. I'm probably not aware of all the intricacies involved in
writing robust maintainer scripts, thus I modelled dh_installsystemduser
after what dh_installsystemd does. The maintainer scripts code blocks
injected by dh_installsystemd stop services in prerm and deactivate them
in postrm, but I don't know if there is a technical reason for that.
The code blocks injected by dh_installsystemduser do not start or stop
services, and I don't see a reason why disabling the services could not
be done in prerm. The relevant maintainr script code block is here [2].
Thanks.
Cheers,
Dan
[1]
https://salsa.debian.org/debian/debhelper/blob/master/autoscripts/postrm-systemd
[2]
https://salsa.debian.org/debian/debhelper/merge_requests/5/diffs?commit_id=163d0b663f75071e6710016960db8581012f4c9c#618769df15efa903bfb94d164eacef2166af740c
