Hi Niels

Am 23.08.21 um 08:19 schrieb Niels Thykier:
Hi systemd maintainers,

I have been asked to backport debhelper to bullseye-backports.

Before I do that, I would like to confirm whether this is sake to
backport for people upgrading from oldstable (+backports) to buster
(+backports)[1].
   As I understand it, support for "usr/lib/systemd/system" was added in
buster and the upgrade would have the systemd from oldstable running
(not to mention the helper scripts used in maintscripts - but that might
be solvable with a Pre-Depends).

Can you help understand that situation and what is needed to make it
safe (or confirm that it cannot be done safely).

systemd in buster (v241) does support reading unit files from
/usr/lib/systemd/system (see systemd-analyze unit-paths).
The changes to init-system-helpers (namely update-rc.d) to also consider unit files in /usr/lib/systemd/system was added in 1.58, i.e. is currently only available in bullseye.

This code path in update-rc.d is only used for older compat levels though. Newer debhelper versions disentangled dh_installinit and dh_installsystemd and we don't use update-rc.d if --skip-systemd-native is used, see commit cba2a8a6ea64773e61ab41c218853ee729656650 in debhelper.

Also, the code in update-rc.d is only a fallback when the "real" systemctl is not available to create the enablement symlinks.

If we hit this code path and update-rc.d does not find the .service file, it silently skips the enablement of the service. The package should still install successfully.

So is it safe? I'd say reasonably so.

Question is, if we should start moving unit files in bullseye(-backports) where everything is installed in /lib from a consistency PoV.

Regards,
Michael

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to