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
