Bug#1117735: Restarting systemd user units on package upgrade
Sean Whitton writes ("Bug#1117735: Restarting systemd user units on package
upgrade"):
> On Wed 03 Dec 2025 at 10:16am GMT, Sean Whitton wrote:
> > Ian, what do you think about something like this:
> >
> > override_dh_installsystemduser:
> > if $(compat 14 is available); then
> > DH_COMPAT=14 dh_installsystemduser ...
> > else
> > dh_installsystemduser ...
> > fi
>
> I.e., on older releases of Debian, dgit-infrastructure.deb will be built
> without restarts of tag2upload-oracled on upgrade.
> (But tag2upload-oracled won't start on those releases anyway, due to
> Perl & Python being too old.)
I think this is a fine approach, assuming we're confident that there
won't be future versions oif dh where this does something undesirable.
(I doubt we can have sensible tests of this? Maybe you can think of a
way...)
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#1117735: Restarting systemd user units on package upgrade
On Wed, 03 Dec 2025 at 12:29:20 +0100, Simon Josefsson wrote:
Will running dh_installsystemduser be useful on systems that doesn't
support compat 14?
It's still useful: in compat levels 12 and 13 it only enables the new
units so they are run on subsequent user logins (by creating symlinks in
/etc/systemd/user/*.target.wants), with the limitation that it does not
restart them for users who already have a `systemd --user` running. This
is how the pipewire{,-pulse} packages work, for example.
ifeq (compat 14 is available)
override_dh_installsystemduser:
DH_COMPAT=14 dh_installsystemduser ...
endif
This construct still runs dh_installsystemduser (if it's in the dh
sequence, which it is, since compat level 12), just without an override,
therefore without any special options.
smcv
Bug#1117735: Restarting systemd user units on package upgrade
Sean Whitton writes: > override_dh_installsystemduser: > if $(compat 14 is available); then > DH_COMPAT=14 dh_installsystemduser ... > else > dh_installsystemduser ... > fi Will running dh_installsystemduser be useful on systems that doesn't support compat 14? So maybe: ifeq (compat 14 is available) override_dh_installsystemduser: DH_COMPAT=14 dh_installsystemduser ... endif /Simon signature.asc Description: PGP signature
Bug#1117735: Restarting systemd user units on package upgrade
Hello, On Wed 03 Dec 2025 at 10:16am GMT, Sean Whitton wrote: > I don't think we mind that dgit-infrastructure.deb starts depending on > dh compat level 14, but the problem is that we want the whole source ^^ I meant: the rest of the source package > Ian, what do you think about something like this: > > override_dh_installsystemduser: > if $(compat 14 is available); then > DH_COMPAT=14 dh_installsystemduser ... > else > dh_installsystemduser ... > fi I.e., on older releases of Debian, dgit-infrastructure.deb will be built without restarts of tag2upload-oracled on upgrade. (But tag2upload-oracled won't start on those releases anyway, due to Perl & Python being too old.) -- Sean Whitton signature.asc Description: PGP signature
Bug#1117735: Restarting systemd user units on package upgrade
On Wed, Dec 03, 2025 at 10:40:26AM +0100, Simon Josefsson wrote: > Holger Levsen writes: > > > On Tue, Dec 02, 2025 at 06:58:48PM +, Simon McVittie wrote: > >> dh_installsystemduser seems to have automation for this, but only in compat > >> level 14, which is opt-in and newer than the default. I don't see a way to > >> opt-in to just that one behaviour of compat level 14 without the rest of > >> it. > > > > so what? we're in level 14 now \o/ > > debhelper in unstable still consider 14 experimental, and trying a B-D > of 'debhelper-compat (= 14)' or X-DH-Compat:14 wasn't pleasant. > > Could we declare it stable? Maybe the debhelper maintainers might chime in here, but my personal opinion (for what it's worth): I've been using compat level 14 for pretty much all my packages (including some team-maintained ones) for years now. My personal experience is that all of the changes that affected my packages made things easier. The only ones that I had to adapt to more than once were those related to dh-sequence-single-binary (source packages that only produce a single binary package), and even then it was only related to packages where I override the invocation of the upstream build system's "install" phase (since for some of my own software I have to set a couple of environment variables); for most packages that was a no-op change, handled by debhelper itself internally. So IMHO debhelper compat level 14 has been ready to be declared stable for some time now. > All Guile packages in Debian that I've reviewed has an ugly workaround > due to dwz problems which level 14 solves. So making 14 stable would be > nice so they can move to it. I don't understand the rest of compat 14 > changes but assume they are all good. > > I'm not sure this solves the problem for dgit though, if you want > something that works for backports. Well, all the changes I like have been pretty much stable in debhelper 13.15.2; bookworm-backports has 13.23. G'luck, Peter -- Peter Pentchev [email protected] [email protected] [email protected] PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1117735: Restarting systemd user units on package upgrade
Hello, On Tue 02 Dec 2025 at 06:58pm GMT, Simon McVittie wrote: > On Tue, 02 Dec 2025 at 15:11:08 +, Sean Whitton wrote: >>We would like the postinst for dgit-infrastructure.deb to restart any >>running instances of [a user service] it finds on the host. > > dh_installsystemduser seems to have automation for this, but only in compat > level 14, which is opt-in and newer than the default. I don't see a way to > opt-in to just that one behaviour of compat level 14 without the rest of it. > > (/usr/share/debhelper/autoscripts/postinst-systemd-user-restart is the > implementation, delegating the actual work to deb-systemd-invoke.) > > See also https://bugs.debian.org/1072698 which tracks new behaviour changes > and the blockers for compat level 14 being stabilized. Oh, thanks! Seems like that's not documented anywhere. I don't think we mind that dgit-infrastructure.deb starts depending on dh compat level 14, but the problem is that we want the whole source package to work on older Debian releases. Currently we run our full test suite back to bullseye. Ian, what do you think about something like this: override_dh_installsystemduser: if $(compat 14 is available); then DH_COMPAT=14 dh_installsystemduser ... else dh_installsystemduser ... fi -- Sean Whitton signature.asc Description: PGP signature
Bug#1117735: Restarting systemd user units on package upgrade
Holger Levsen writes: > On Tue, Dec 02, 2025 at 06:58:48PM +, Simon McVittie wrote: >> dh_installsystemduser seems to have automation for this, but only in compat >> level 14, which is opt-in and newer than the default. I don't see a way to >> opt-in to just that one behaviour of compat level 14 without the rest of it. > > so what? we're in level 14 now \o/ debhelper in unstable still consider 14 experimental, and trying a B-D of 'debhelper-compat (= 14)' or X-DH-Compat:14 wasn't pleasant. Could we declare it stable? All Guile packages in Debian that I've reviewed has an ugly workaround due to dwz problems which level 14 solves. So making 14 stable would be nice so they can move to it. I don't understand the rest of compat 14 changes but assume they are all good. I'm not sure this solves the problem for dgit though, if you want something that works for backports. /Simon signature.asc Description: PGP signature
Bug#1117735: Restarting systemd user units on package upgrade
On Tue, Dec 02, 2025 at 06:58:48PM +, Simon McVittie wrote: > dh_installsystemduser seems to have automation for this, but only in compat > level 14, which is opt-in and newer than the default. I don't see a way to > opt-in to just that one behaviour of compat level 14 without the rest of it. so what? we're in level 14 now \o/ -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "... the premise [is] that privacy is about hiding a wrong. It's not. Privacy is an inherent human right, and a requirement for maintaining the human condition with dignity and respect." (Bruce Schneier) signature.asc Description: PGP signature
Bug#1117735: Restarting systemd user units on package upgrade
On 2025-12-02 18:58 +, Simon McVittie wrote: > On Tue, 02 Dec 2025 at 15:11:08 +, Sean Whitton wrote: >>We would like the postinst for dgit-infrastructure.deb to restart any >>running instances of [a user service] it finds on the host. > > dh_installsystemduser seems to have automation for this, but only in > compat level 14, which is opt-in and newer than the default. I don't > see a way to opt-in to just that one behaviour of compat level 14 > without the rest of it. At least it is possible to limit the behaviour changes to that particular command via debian/rules, and this is usually good enough. override_dh_installsystemduser: DH_COMPAT=14 dh_installsystemduser [...] Cheers, Sven
Bug#1117735: Restarting systemd user units on package upgrade
On Tue, 02 Dec 2025 at 15:11:08 +, Sean Whitton wrote: We would like the postinst for dgit-infrastructure.deb to restart any running instances of [a user service] it finds on the host. dh_installsystemduser seems to have automation for this, but only in compat level 14, which is opt-in and newer than the default. I don't see a way to opt-in to just that one behaviour of compat level 14 without the rest of it. (/usr/share/debhelper/autoscripts/postinst-systemd-user-restart is the implementation, delegating the actual work to deb-systemd-invoke.) See also https://bugs.debian.org/1072698 which tracks new behaviour changes and the blockers for compat level 14 being stabilized. smcv
Bug#1117735: Restarting systemd user units on package upgrade
Hello, The tag2upload signing oracle is installed on the DSA host that has the signing YubiKey by dgit-infrastructure.deb, and the daemon is started by a role user as a systemd user unit. We would like the postinst for dgit-infrastructure.deb to restart any running instances of the Oracle daemon it finds on the host. In practice there will only ever be one, but with it being a user unit, the postinst will have to search for user instances of systemd and see if they are running the service, then cause them to restart it. Has anyone implemented something like this already? Does anyone have any tips on how to achieve it? How would you search for user instances of systemd that might be running services? -- Sean Whitton signature.asc Description: PGP signature
