[Pkg-libvirt-maintainers] Bug#1064126: Bug#1064126: libvirt: install NSS modules into /usr

[Helmut Grohne]

Hi Andrea,

On Tue, Aug 27, 2024 at 01:31:59AM +0200, Andrea Bolognani wrote:
> 10.6.0-2, which includes the changes, is now in experimental. Thanks
> again for taking care of the upload, in addition to reviewing and
> testing everything, Guido!

Thanks as well.

> Do we need to do anything to cause dumat do do its thing, or will
> that happen automatically? And will you (Helmut, Michael) let us know
> what the outcome of its analysis is, or is that something that we
> will need to look up ourselves?

dumat already did its work. Your ping was still helpful. Please do not
upload libvirt to unstable as is. I'll copy the relevant yaml report
here for reference:

libvirt-daemon:
  10.6.0-2:
    issues:
    - files:
      - /usr/lib/systemd/system/libvirtd-admin.socket
      - /usr/lib/systemd/system/libvirtd-ro.socket
      - /usr/lib/systemd/system/libvirtd-tcp.socket
      - /usr/lib/systemd/system/libvirtd-tls.socket
      - /usr/lib/systemd/system/libvirtd.service
      - /usr/lib/systemd/system/libvirtd.socket
      others:
        libvirt-daemon-system:
          10.6.0-1: trixie|unstable
          7.0.0-3+deb11u2: bullseye
          7.0.0-3+deb11u3: bullseye-proposed-updates
          8.0.0-1~bpo11+1: bullseye-backports
          9.0.0-4: bookworm
          9.0.0-4+deb12u1: bookworm-proposed-updates
      what: ineffective replaces
    source: libvirt
    suites: experimental
libvirt-daemon-common:
  10.6.0-2:
    issues:
    - files:
      - /usr/lib/systemd/system/libvirt-guests.service
      - /usr/lib/systemd/system/virt-guest-shutdown.target
      others:
        libvirt-daemon-system:
          10.6.0-1: trixie|unstable
          7.0.0-3+deb11u2: bullseye
          7.0.0-3+deb11u3: bullseye-proposed-updates
          8.0.0-1~bpo11+1: bullseye-backports
          9.0.0-4: bookworm
          9.0.0-4+deb12u1: bookworm-proposed-updates
      what: ineffective replaces
    source: libvirt
    suites: experimental
libvirt-daemon-lock:
  10.6.0-2:
    issues:
    - files:
      - /usr/lib/systemd/system/virtlockd-admin.socket
      - /usr/lib/systemd/system/virtlockd.service
      - /usr/lib/systemd/system/virtlockd.socket
      others:
        libvirt-daemon-system:
          10.6.0-1: trixie|unstable
          7.0.0-3+deb11u2: bullseye
          7.0.0-3+deb11u3: bullseye-proposed-updates
          8.0.0-1~bpo11+1: bullseye-backports
          9.0.0-4: bookworm
          9.0.0-4+deb12u1: bookworm-proposed-updates
      what: ineffective replaces
    source: libvirt
    suites: experimental
libvirt-daemon-log:
  10.6.0-2:
    issues:
    - files:
      - /usr/lib/systemd/system/virtlogd-admin.socket
      - /usr/lib/systemd/system/virtlogd.service
      - /usr/lib/systemd/system/virtlogd.socket
      others:
        libvirt-daemon-system:
          10.6.0-1: trixie|unstable
          7.0.0-3+deb11u2: bullseye
          7.0.0-3+deb11u3: bullseye-proposed-updates
          8.0.0-1~bpo11+1: bullseye-backports
          9.0.0-4: bookworm
          9.0.0-4+deb12u1: bookworm-proposed-updates
      what: ineffective replaces
    source: libvirt
    suites: experimental

Reading this is not trivial. The common pattern is "what: ineffective
replaces", which means you have DEP17 P1 problems. Refer to
https://subdivi.de/~helmut/dep17.html for what that means precisely.
They're all of the kind where you move a systemd unit around from one
package to another and at the same time from /lib/systemd/system to
/usr/lib/systemd/system.

We may choose between M7 (upgrading Replaces to Conflicts), M8
(protective diversions) and a combination of both. Given that libvirt
may be critical to some systems, I suggest that M7 is not sufficiently
reliable on its own. Doing M8 only is what we tend to do for really
critical things such as e2fsprogs, but it has the cost of persisting
protective diversions into the actual system. By combining both, we can
remove the protective diversions at the end of the upgrade process such
that they are gone once the system is upgraded to trixie and you get to
remove the mitigation code after trixie is released. I suggest that the
last option is a good trade-off for libvirt in terms of safety vs
effort. Do you agree? Please don't hesitate to ask if this is unclear.

Let me sketch how to apply M7+M8. For each ineffective replaces, we
upgrade Breaks+Replaces to Conflicts in debian/control. Additionally, we
add code to preinst and postinst for each affected file. For example
libvirt-daemon-log.preinst would dpkg-divert --divert
/lib/systemd/system/virtlogd.socket.usr-is-merged --no-rename --add
/lib/systemd/system/virtlogd.socket and libvirt-daemon-log.postinst and
libvirt-daemon-log.postrm would remove the diversion. It is diverting
the aliased path that is formerly installed by libvirt-daemon-system and
not the canonical path installed by libvirt-daemon-log. Hence, lintian
may be annoyed.

Do you prefer receiving a patch with these mitigations against the
experimental package or do you prefer implementing this yourself?

> Assuming no issues are detected, I would like to upload 10.7.0-1 with
> these changes and the new upstream release to unstable in a week or
> so, but I can delay that for a bit if more time is needed.

Yes, please delay. We need one more experimental upload to confirm the
correctness of the mitigations.

Helmut