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: Bug#992554: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system
On Fri, 2021-08-20 at 19:15 +0100, Simon McVittie wrote:
> On Fri, 20 Aug 2021 at 19:01:00 +0100, Luca Boccassi wrote:
> > I can confirm that if you build in split-usr mode then the generators
> > are looked for only in /lib:
> >
> > https://github.com/systemd/systemd/blob/v247/meson.build#L156
> >
> > (the systemgeneratordir meson variable is set from rootlibexecdir which
> > is /lib/systemd/ in this case, this applies to other paths too)
> >
> > At this point this is very very unlikely to change upstream, given the
> > legacy split mode is about to be dropped.
> >
> > However it would be trivial to patch it downstream, basically add the
> > path here:
> >
> > https://github.com/systemd/systemd/blob/v247/src/basic/path-lookup.c#L800
>
> Note that if we patch this downstream during the bookworm cycle, then
> debhelper will have to add a version constraint to the affected packages,
> to make sure partial upgrades pull in a suitable version of systemd.
> Moving /lib/systemd/system/* to /usr/lib/systemd/system/ was only OK
> because it was already supported by bullseye's systemd and
> init-system-helpers, and we don't support skipping a release.
>
> I said ${misc:Depends} before, but now I realise it would have to be a
> new ${misc:Breaks} instead, otherwise packages like tor would pull in
> systemd on systems that previously booted with sysvinit, and we'd have
> a whole new flamewar.
>
> Honestly, I'm not sure it's worth the bug risk of doing that - if
> merged-/usr becomes required (as per the TC resolution) then everything
> is going to end up physically located in /usr anyway, even if it's
> canonically in /lib according to the dpkg database (and then we can move
> everything into /usr at our leisure, during the bookworm+1 cycle).
>
> smcv
Yes I pretty much agree with your assessment, just wanted to provide
options.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Re: Bug#992554: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system
On Fri, 20 Aug 2021 at 19:01:00 +0100, Luca Boccassi wrote:
> I can confirm that if you build in split-usr mode then the generators
> are looked for only in /lib:
>
> https://github.com/systemd/systemd/blob/v247/meson.build#L156
>
> (the systemgeneratordir meson variable is set from rootlibexecdir which
> is /lib/systemd/ in this case, this applies to other paths too)
>
> At this point this is very very unlikely to change upstream, given the
> legacy split mode is about to be dropped.
>
> However it would be trivial to patch it downstream, basically add the
> path here:
>
> https://github.com/systemd/systemd/blob/v247/src/basic/path-lookup.c#L800
Note that if we patch this downstream during the bookworm cycle, then
debhelper will have to add a version constraint to the affected packages,
to make sure partial upgrades pull in a suitable version of systemd.
Moving /lib/systemd/system/* to /usr/lib/systemd/system/ was only OK
because it was already supported by bullseye's systemd and
init-system-helpers, and we don't support skipping a release.
I said ${misc:Depends} before, but now I realise it would have to be a
new ${misc:Breaks} instead, otherwise packages like tor would pull in
systemd on systems that previously booted with sysvinit, and we'd have
a whole new flamewar.
Honestly, I'm not sure it's worth the bug risk of doing that - if
merged-/usr becomes required (as per the TC resolution) then everything
is going to end up physically located in /usr anyway, even if it's
canonically in /lib according to the dpkg database (and then we can move
everything into /usr at our leisure, during the bookworm+1 cycle).
smcv
Re: Bug#992554: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system
On Fri, 2021-08-20 at 18:30 +0100, Simon McVittie wrote:
> Control: retitle 992554 debhelper: moves systemd system generators to a
> location not searched by systemd
> Control: reassign 992554 debhelper 13.4
> Control: affects 992554 + tor ostree
>
> On Fri, 20 Aug 2021 at 16:20:04 +, Peter Palfrader wrote:
> > 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.
>
> I think debhelper should *not* be moving anything from /lib/systemd/
> to /usr/lib/systemd/, except for /lib/systemd/system/, which we have
> confirmed is OK. Other directories like /lib/systemd/system-generators
> are not necessarily going to be searched on non-merged-/usr systems;
> before moving any particular class of systemd-related files, debhelper
> developers should confirm with the systemd maintainers that systemd
> is already looking in both locations, and since which version (so that
> appropriate ${misc:Depends} can be added if required).
>
> On merged-/usr systems (with aliasing symlinks like /lib -> usr/lib,
> as created by usrmerge and debootstrap --merged-usr), this is of course
> a non-issue, but we do not all have merged-/usr systems yet.
>
> I think this is a nice illustration of the things that can go wrong on
> non-merged-/usr systems, when we move individual categories of files
> from the rootfs into /usr, in order to achieve the same result as
> merged-/usr (but with more effort and more complexity).
>
> smcv
I can confirm that if you build in split-usr mode then the generators
are looked for only in /lib:
https://github.com/systemd/systemd/blob/v247/meson.build#L156
(the systemgeneratordir meson variable is set from rootlibexecdir which
is /lib/systemd/ in this case, this applies to other paths too)
At this point this is very very unlikely to change upstream, given the
legacy split mode is about to be dropped.
However it would be trivial to patch it downstream, basically add the
path here:
https://github.com/systemd/systemd/blob/v247/src/basic/path-lookup.c#L800
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Re: Bug#992554: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system
Control: retitle 992554 debhelper: moves systemd system generators to a
location not searched by systemd
Control: reassign 992554 debhelper 13.4
Control: affects 992554 + tor ostree
On Fri, 20 Aug 2021 at 16:20:04 +, Peter Palfrader wrote:
> 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.
I think debhelper should *not* be moving anything from /lib/systemd/
to /usr/lib/systemd/, except for /lib/systemd/system/, which we have
confirmed is OK. Other directories like /lib/systemd/system-generators
are not necessarily going to be searched on non-merged-/usr systems;
before moving any particular class of systemd-related files, debhelper
developers should confirm with the systemd maintainers that systemd
is already looking in both locations, and since which version (so that
appropriate ${misc:Depends} can be added if required).
On merged-/usr systems (with aliasing symlinks like /lib -> usr/lib,
as created by usrmerge and debootstrap --merged-usr), this is of course
a non-issue, but we do not all have merged-/usr systems yet.
I think this is a nice illustration of the things that can go wrong on
non-merged-/usr systems, when we move individual categories of files
from the rootfs into /usr, in order to achieve the same result as
merged-/usr (but with more effort and more complexity).
smcv
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
WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system
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... - Ted
