vcswatch reports that
this package seems to have new commits in its VCS but has
not yet updated debian/changelog. You should consider updating
the Debian changelog and uploading this new version into the archive.
Here are the relevant commit logs:
commit 904900c36dab4f69c1e7f3d700eef4b6bea42268
Author: Andrea Bolognani <eof@kiyuko.org>
Date: Sat Mar 15 15:40:32 2025 +0100
control: Drop more unnecessary package relationships
All these Depends and Recommends were only introduced in an
attempt to ensure that maintainer scripts would run in the
specific order that our custom conffile transfer logic
expected. Now that we're no longer relying on said custom
logic, we can get rid of them.
Notably, this will result in non-QEMU hypervisor drivers
no longer being installed by default when the daemon-system
package is installed, thus making it fulfill its intended
purpose much better.
commit efe5fbc1802ec04703ae7c0459994ddd7f1c8657
Author: Andrea Bolognani <eof@kiyuko.org>
Date: Sat Mar 15 15:39:07 2025 +0100
daemon: Drop Recommends on non-QEMU hypervisor drivers
The various hypervisor drivers were moved to their own
packages way back in 2018, and at that time they were kept
as Recommends so that users would not be hit by unexpected
functionality loss after upgrading.
At this point, anyone upgrading will already have the
specific packages installed, so these Recommends no longer
serve any useful purpose; on the contrary, they can result
in undesired hypervisor drivers getting automatically
dragged in during upgrade or initial installation.
We retain the Recommends for the QEMU driver for now,
because we know that there are packages in Debian which
need the QEMU driver and don't depend on it explicitly,
instead relying on the daemon package dragging it in.
That's something that we should sort out eventually, but
for now let's avoid the potential disruption.
commit 9e2b202545f1d419409c414e1aec7c61d3f2a35a
Author: Andrea Bolognani <eof@kiyuko.org>
Date: Mon Feb 17 00:00:39 2025 +0100
snippets: Drop custom conffile transfer logic
This logic was introduced with the intent to smoothly transfer
conffiles between binary packages. It was initially used in just
a few scenarios, but with last year's big rework its use was
significantly expanded.
More recently, two important flaws have been identified with
this approach:
* since our logic requires maintscripts to be called in a
very specific order, we have added several Depends and
Recommends relationships between packages specifically to
enforce that. However, dpkg can sometimes reorder
operations in ways that break our assumptions while still
being entirely compliant with Policy;
* conffiles that have been modified by the local admin are
always preserved as is, even when the file shipped in the
package has been modified between the two versions
involved in the upgrade. The expectation is that the user
will be prompted so that they can decide how to handle
the situation instead.
Luckily, it turns out that dpkg already does a very good job
at coping with conffiles moving between packages, so we can
just rip out our custom logic completely and that will solve
both issues at once.
There are a couple of minor drawbacks:
* depending on the order in which packages are unpacked,
which we have no control over, the package which used to
own the conffile might end up still having a record of
that, though it will be marked as "obsolete". This is
primarily a cosmetic issue, and it can for the most part
be addressed by simply reinstalling the package. We are
likely going to inform users about this in the trixie
release notes;
* conffiles that had been deleted might get recreated.
This is a bit annoying and there is no convenient way
to prevent it from happening, but there's no actual
functional impact as libvirt behaves the same way
whether the conffile doesn't exist or only contains
comments, as is the default.
The benefits very clearly outweigh the drawbacks, so we're
making the switch.
Closes: #1094583
![[bug history graph]](https://qa.debian.org/data/bts/graphs/libv/libvirt.png){kind=link}