Web lists-archives.com

Re: Versioned dependencies and maintainer scripts

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