On Thu, Aug 19, 2021 at 12:18:51AM -0400, Theodore Ts'o wrote: > There appears to be a rather major regression in debhelper 1.13.4 and > 1.13.4nmu1, which is forcing unit files to go in > /usr/lib/systemd/system, instead of /lib/systemd/systemd (where sytemd > will actually pay attention to them). > > On systems with ursmerge, things should still work, thanks to the > compatibility symlink, but this will cause packages with unit files > built since debhelper 1.13.4 was released to unstable, or uploaded as > source builds, to be incorrect, triggering a Lintian error and > breaking on systems that don't have usrmerge installed. > > For more details and analysis, please see: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992469 > > I just wanted to post a warning that if you were planning on building > or uploading new source-only uploads to unstable now that Bullseye has > been released, and your package contains systemd unit files, you may > want to hold off until this bug gets fixed... Actually, I just reported #992465 against Lintian last night: the Lintian error is outdated. See the original message in #987989 that prompted the debhelper change: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987989#5 I got a scare yesterday, too, when I noticed a local rebuild moved a unit file to /usr/lib/systemd/system/, but then I read #987989 and then I actually tried it - and systemd happily found my service and started it. So, it's not as bad as it looks at first :) G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@debian.org pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Attachment:
signature.asc
Description: PGP signature