Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.devel > #109501
| 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 |
[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
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