Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system
155 views
Skip to first unread message
Theodore Ts'o
Aug 19, 2021, 12:40:03 AM8/19/21
to
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
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
Peter Pentchev
Aug 19, 2021, 2:00:03 AM8/19/21
to
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 ro...@ringlet.net ro...@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
Michael Biebl
Aug 19, 2021, 2:50:03 AM8/19/21
to
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.
> 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).
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
Michael Biebl
Aug 19, 2021, 6:10:03 AM8/19/21
to
Am 19.08.21 um 08:27 schrieb Michael Biebl:
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
> 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].
> 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.
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
Theodore Ts'o
Aug 19, 2021, 10:50:02 AM8/19/21
to
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
> 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.
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
Michael Biebl
Aug 19, 2021, 3:30:03 PM8/19/21
to
Am 19.08.21 um 16:28 schrieb Theodore Ts'o:
I'll see that this is going to be fixed.
Thanks for raising this issue.
Michael
> 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.
> 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.
I'll see that this is going to be fixed.
Thanks for raising this issue.
Michael
Simon McVittie
Aug 20, 2021, 1:40:03 PM8/20/21
to
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 +0000, 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
Control: reassign 992554 debhelper 13.4
Control: affects 992554 + tor ostree
On Fri, 20 Aug 2021 at 16:20:04 +0000, 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
Simon McVittie
Aug 20, 2021, 2:30:03 PM8/20/21
to
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
> 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
Felix Lechner
Aug 22, 2021, 12:30:03 PM8/22/21
to
Hi,
On Thu, Aug 19, 2021 at 2:57 AM Luca Boccassi <bl...@debian.org> 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
On Thu, Aug 19, 2021 at 2:57 AM Luca Boccassi <bl...@debian.org> wrote:
>
> updating Lintian would be the best outcome.
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
0 new messages