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

Groups > linux.debian.devel > #109501 > unrolled thread

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

Back to article view | Back to linux.debian.devel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

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

[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.

[toc] | [next] | [standalone]

#109503

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

[toc] | [prev] | [next] | [standalone]

#109504

Hi Andrea,

On Mon, Oct 09, 2023 at 02:10:27PM +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.

This definitely is more common, yes.

> 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?

In the long run, I definitely agree. In the short term, there are
downsides.

> 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.

This is correct. systemd handles both locations since very long. 

> 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.

Yes, you are and what you are missing really is not obvious, so thanks
for asking!

For one thing, dh_installsystemd generates maintainer scripts for
restarting services. Before version 13.11.6, it did not recognize the
/usr location. If you were to backport such a package, bookworm's
debhelper would not generate the relevant maintainer scripts. You can
mitigate this by issuing "Build-Depends: debhelper (>= 13.11.6~)". Thus,
you'll be using a backported debhelper (unless the backporter carelessly
deletes this dependency).

For another, we have this generic file loss problem (DEP17 P1). If - in
addition to moving units to /usr - you also restructure your package
between bookworm and trixie (move units between binary packages), then
an upgrade scenario may delete those files even in the presence of
correct Breaks+Replaces. As long as you are sure that you do not rename
any binary packages nor move any units between packages from bookworm to
trixie, this won't apply. Such renames or moves are hard to predict
though.

So if you understand these limitations and are prepared to handle them
for backports, cleaning things up now is fine. If you are not, deferring
that cleanup until after trixie and using dh_movetousr in the interim,
may be the simpler option.

Helmut

[toc] | [prev] | [next] | [standalone]

#109509

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

On Mon, Oct 09, 2023 at 08:16:32PM +0200, Helmut Grohne wrote:
> On Mon, Oct 09, 2023 at 02:10:27PM +0200, Andrea Bolognani wrote:
> > Am I missing something?
> 
> Yes, you are and what you are missing really is not obvious, so thanks
> for asking!
> 
> For one thing, dh_installsystemd generates maintainer scripts for
> restarting services. Before version 13.11.6, it did not recognize the
> /usr location. If you were to backport such a package, bookworm's
> debhelper would not generate the relevant maintainer scripts. You can
> mitigate this by issuing "Build-Depends: debhelper (>= 13.11.6~)". Thus,
> you'll be using a backported debhelper (unless the backporter carelessly
> deletes this dependency).

You mentioned this constraint in your original email, so while I
didn't mention it explicitly I was planning on adding the necessary
Build-Depends. I was also assuming that a good enough version of
debhelper would be backported to bookworm.

> For another, we have this generic file loss problem (DEP17 P1). If - in
> addition to moving units to /usr - you also restructure your package
> between bookworm and trixie (move units between binary packages), then
> an upgrade scenario may delete those files even in the presence of
> correct Breaks+Replaces. As long as you are sure that you do not rename
> any binary packages nor move any units between packages from bookworm to
> trixie, this won't apply. Such renames or moves are hard to predict
> though.

I'm actually hoping that I will be able to get around to a pretty big
refactoring of the libvirt package before trixie, so this is kind of
a deal breaker for me :)

> So if you understand these limitations and are prepared to handle them
> for backports, cleaning things up now is fine. If you are not, deferring
> that cleanup until after trixie and using dh_movetousr in the interim,
> may be the simpler option.

Yup, given the situation dh_movetousr definitely feels like the way
to go.

Thank you for taking the time to explain the situation and, once
again, for all your tireless work in this area :)

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

[toc] | [prev] | [next] | [standalone]

#109513

Hi,

On 10/10/23 03:16, Helmut Grohne wrote:

> For one thing, dh_installsystemd generates maintainer scripts for
> restarting services. Before version 13.11.6, it did not recognize the
> /usr location. If you were to backport such a package, bookworm's
> debhelper would not generate the relevant maintainer scripts. You can
> mitigate this by issuing "Build-Depends: debhelper (>= 13.11.6~)". Thus,
> you'll be using a backported debhelper (unless the backporter carelessly
> deletes this dependency).

If that would be the only reason to require a backported debhelper, then 
it would probably be better to make the file move conditional on the 
target distribution (from "dpkg-parsechangelog -S distribution") -- the 
intention of that is immediately readable, while a versioned build 
dependency needs to be explained or a backporter might want to 
carelessly delete it.

gcc does something similar, although that uses "lsb_release -cs", which 
is technically not entirely correct since it looks at the build system, 
not the current package, but for the purpose of backports is good enough 
and avoids corner cases like "stable-proposed-updates" not matching 
"bookworm" or "bookworm-backports".

    Simon

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.devel

csiph-web