Michael Biebl: > Hi Niels > > Am 23.08.21 um 08:19 schrieb Niels Thykier: >> [...] > > 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. >
Thanks for the analysis. :) > 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. > My reptile brain reaction to this is that it smells like "fails to install correctly and failing to declare to do so" if we do not enable a system when we should have. I get that most installations that do not have systemd are unlikely to switch to systemd later but I do want it to "just work(tm)". > Question is, if we should start moving unit files in > bullseye(-backports) where everything is installed in /lib from a > consistency PoV. > > Regards, > Michael > That is the crux of this request. The backport was requested to ensure consistency between bullseye and buster builds (see the OP for details; I omitted them in my forward to you as I thought they were irrelevant to my question). Personally, it is easier for me if both cases use the same path but only if works for -backports as well. If we are not certain it is safe, then I will look at using /lib for -backports even if it means I cannot comply with this request. Thanks, ~Niels
