Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.devel > #109501

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

From Andrea Bolognani <eof@kiyuko.org>
Newsgroups linux.debian.devel
Subject Re: /usr-merge and DEP17 update: what happens next and how you can help
Date 2023-10-09 14:20 +0200
Message-ID <HmXoR-eBTt-1@gated-at.bofh.it> (permalink)
References <HmIzw-esqD-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

On Sun, Oct 08, 2023 at 10:25:44PM +0200, Helmut Grohne wrote:
>  * For many other cases, I propose leaving the upstream install layout
>    as is and performing the conversion using a new debhelper component
>    that will be called dh_movetousr
> 
[...]
> 
>  * movetousr.ddlist lists packages that probably need to run
>    dh_movetousr for some reason:
>     + There are other files than systemd units shipped in aliased
>       locations.
>     + debian/*.install places units to /lib. In this case, consider
>       installing units by placing them to debian/*.service if possible
>       to benefit from the automatic conversion.
>     + An upstream build system hard codes the systemd unit location to
>       /lib.
>     + ...
> 
[...]
> 
> Debian Libvirt Maintainers <pkg-libvirt-maintainers@lists.alioth.debian.org>
>    libvirt

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?

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.

Am I missing something? I have to admit that, while I've tried to
keep tabs on the discussion and all the great work you and other have
been doing to push things forward, I never quite managed to fully
absorb the problem space.

-- 
Andrea Bolognani <eof@kiyuko.org>
Resistance is futile, you will be garbage collected.

Back to linux.debian.devel | Previous | Next — Next in thread | Find similar | Unroll thread


Thread

Re: /usr-merge and DEP17 update: what happens next and how you can  help Andrea Bolognani <eof@kiyuko.org> - 2023-10-09 14:20 +0200
  Re: /usr-merge and DEP17 update: what happens next and how you can  help Sven Joachim <svenjoac@gmx.de> - 2023-10-09 20:20 +0200
  Re: /usr-merge and DEP17 update: what happens next and how you can  help Helmut Grohne <helmut@subdivi.de> - 2023-10-09 20:30 +0200
    Re: /usr-merge and DEP17 update: what happens next and how you can  help Andrea Bolognani <eof@kiyuko.org> - 2023-10-10 00:30 +0200
    Re: /usr-merge and DEP17 update: what happens next and how you can  help Simon Richter <sjr@debian.org> - 2023-10-10 08:20 +0200

csiph-web