[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /usr-merge and DEP17 update: what happens next and how you can help



On 2023-10-09 14:10 +0200, Andrea Bolognani wrote:

> For libvirt, the upstream build system actually installs systemd
> units under /usr/lib, and we move things around in debian/rules so
> that they end up under /lib in the Debian package:
>
>   SRV_MONOLITHIC = libvirt-guests virtlogd virtlockd \
>                    libvirtd libvirtd-tcp libvirtd-tls virt-guest-shutdown
>
>   set -e; for f in $(SRV_MONOLITHIC); do \
>       dh_install -p libvirt-daemon-system \
>                  usr/lib/systemd/system/$${f}* \
>                  lib/systemd/system/; \
>   done
>
> I wouldn't be surprised if other packages did something similar.
>
> In this case, instead of throwing dh_movetousr into the mix, wouldn't
> it be more sensible to drop the rename part and just follow the
> upstream build system?

Makes sense to me, but there is one caveat.

> I guess this could theoretically be problematic for backports, as the
> dh_movetousr approach would guarantee that units still end up in /lib
> on bookworm and older but this wouldn't. On the other hand, hasn't
> systemd been able to load units both from /lib and /usr/lib for
> several releases now? So I would expect that to work somewhat
> transparently.

While systemd has supported units both under /lib/systemd/system and
/usr/lib/systemd/system for years, dh_installsystemd has only gained
support for the latter in the latest debhelper upload.

So if you install systemd units there, adding a build-dependency on
debhelper (>= 13.11.6~) is probably advisable, lest backports run into
#1041159[1].

Cheers,
       Sven


1. https://bugs.debian.org/1041159


Reply to: