Versioned dependencies and maintainer scripts

Daniele Nicolodi

unread,

Jun 24, 2018, 7:10:02 PM6/24/18

to

Hello,

I'm adding dh_installsystemduser to debhelper, to support user instance
systemd units, similarly to what dh_installsystemd does for system
unists. For doing so I had to extend deb-systemd-helper from the
init-system-helper package to handle user units. User units support will
hopefully be released with the next release of init-system-helpers.

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?

Thanks.

Cheers,
Dan

Simon McVittie

unread,

Jun 25, 2018, 3:10:03 AM6/25/18

to

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

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.

Most packages do the more involved parts of their removal in the prerm.
Is that feasible here?

smcv

Daniele Nicolodi

unread,

Jun 25, 2018, 1:20:03 PM6/25/18

to

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

Wouter Verhelst

unread,

Jun 28, 2018, 8:50:02 AM6/28/18

to

On Mon, Jun 25, 2018 at 08:04:01AM +0100, 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
>
> 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).

Additionally, unless you have a circular dependency involved somewhere
(and you really should try to avoid that if you can), then the package
will also be configured, so all will be good.

(All that to say that I agree and that no, you shouldn't need
Pre-Depends here)

--
Could you people please use IRC like normal people?!?

-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab

Adrian Bunk

unread,

Jul 8, 2018, 4:40:03 AM7/8/18

to

On Mon, Jun 25, 2018 at 11:10:51AM -0600, Daniele Nicolodi wrote:
>...

> On 6/25/18 1:04 AM, Simon McVittie wrote:

>...

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

>...

"purge" might happen decades (sic) after "remove" with no dependencies
installed and packages that are essential today no longer being essential.

> Cheers,
> Dan
>...

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed