Re: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system
Hi, On Thu, Aug 19, 2021 at 2:57 AM Luca Boccassi wrote: > > updating Lintian would be the best outcome. The corresponding bug in Lintian [1] will be resolved by changing the expected prefix for service files to /usr/lib once a backport of debhelper is available in bullseye, as described here. [2] Kind regards Felix Lechner [1] https://bugs.debian.org/992465 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992711#5
Re: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system
On Thu, 19 Aug 2021, Luca Boccassi wrote: > > Installing those files in /usr/lib/systemd/system is fine. > > > > This is indeed the right thing to do moving forward, so updating > Lintian would be the best outcome. Thanks! It seems that generators in /usr/lib/systemd are being ignored. This causes #992554 in tor. The tor amd64 package build on the buildds has the systemd files in /usr/lib/systemd, and this results in a broken package. Moving /usr/lib/systemd/system-generators/tor-generator tor /lib/systemd/system-generators "fixes" the issue. Probably debhelper should not move generators to /usr until systemd also checks that tree for generators. Or I'm missing something else. Cheers, -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Re: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system
Am 19.08.21 um 16:28 schrieb Theodore Ts'o: OK, thanks for confirming this. What really worried me was this text in lintian: N: Systemd in Debian searches for unit files in /lib/systemd/system/ and N: /etc/systemd/system. Notably, it does *not* look in N: /usr/lib/systemd/system/ for service files. This warning is definitely wrong/outdated. I'll see that this is going to be fixed. Thanks for raising this issue. Michael OpenPGP_signature Description: OpenPGP digital signature
Re: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system
On Thu, Aug 19, 2021 at 11:46:21AM +0200, Michael Biebl wrote: > Am 19.08.21 um 08:27 schrieb Michael Biebl: > > I'll check later today, if i-s-h (init-system-helpers) does properly > > handle this new path. If so, I'd say the bug should be reassigned to > > lintian and we should start transitioning the files to > > /usr/lib/systemd/system. > > I now remember updating i-s-h [1]. > > So we should be safe using /usr/lib/systemd/system I'd say. OK, thanks for confirming this. What really worried me was this text in lintian: N: Systemd in Debian searches for unit files in /lib/systemd/system/ and N: /etc/systemd/system. Notably, it does *not* look in N: /usr/lib/systemd/system/ for service files. This implied that it was *systemd* that didn't like /usr/lib/systemd, and I didn't understand the subtlty that it was really the how Debian's init-system-helpers worked which was the issue. So it sounds like it's OK for me to upload a package like e2fsprogs with a systemd unit file, despite the lintian flagging this as an error. - Ted
Re: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system
Am 19.08.21 um 08:27 schrieb Michael Biebl: I'll check later today, if i-s-h (init-system-helpers) does properly handle this new path. If so, I'd say the bug should be reassigned to lintian and we should start transitioning the files to /usr/lib/systemd/system. I now remember updating i-s-h [1]. So we should be safe using /usr/lib/systemd/system I'd say. There is a cosmetic issue that the enablement symlinks in /etc/systemd/system/*.target/ will now be dangling on unmerged systems (they will point at the files in /lib/systemd/system). But systemd will consider such services as enabled. At least, as long we still build systemd with split-usr support. If anyone wants to provide a patch to fixup such symlinks on upgrades, then this would be nice. Michael [1] https://salsa.debian.org/debian/init-system-helpers/-/commit/552e993488a403bf88aa342f73bf0b22ce62ff16 OpenPGP_signature Description: OpenPGP digital signature
Re: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system
On Thu, 2021-08-19 at 08:27 +0200, Michael Biebl wrote: > Am 19.08.2021 um 06:18 schrieb Theodore Ts'o: > > 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). > > > Installing those files in /usr/lib/systemd/system is fine. > systemd itself will handle them just as well as when they are installed > in /lib/systemd/system (see systemd-analyze unit-paths). > It's our own tooling (debhelper, i-s-h, lintian) which preferred a > single path, i.e. /lib/systemd/system. > > I wanted to get debhelper updated anyway in the bookworm release cycle > to prefer /usr/lib/systemd/system over /lib/systemd/system, but > obviously this should have happened in a more orderly fashion, i.e. > lintian would have been updated first. > > I'll check later today, if i-s-h (init-system-helpers) does properly > handle this new path. If so, I'd say the bug should be reassigned to > lintian and we should start transitioning the files to > /usr/lib/systemd/system. > > > Michael This is indeed the right thing to do moving forward, so updating Lintian would be the best outcome. Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system
Am 19.08.2021 um 06:18 schrieb Theodore Ts'o: 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). Installing those files in /usr/lib/systemd/system is fine. systemd itself will handle them just as well as when they are installed in /lib/systemd/system (see systemd-analyze unit-paths). It's our own tooling (debhelper, i-s-h, lintian) which preferred a single path, i.e. /lib/systemd/system. I wanted to get debhelper updated anyway in the bookworm release cycle to prefer /usr/lib/systemd/system over /lib/systemd/system, but obviously this should have happened in a more orderly fashion, i.e. lintian would have been updated first. I'll check later today, if i-s-h (init-system-helpers) does properly handle this new path. If so, I'd say the bug should be reassigned to lintian and we should start transitioning the files to /usr/lib/systemd/system. Michael
Re: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system
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 r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
