On 1/19/26 12:02, 张攀 wrote:
Hi Michael,
> I wonder how upgrade worked in my testing..
I strongly suspect your testing involved upgrading from **Stable
(Bookworm)** or **Testing (Trixie)**, where the installed `qemu-user-
static` version is older (e.g., 1:8.x or 1:9.0).
Since those older versions are `< 1:9.1.0`, the existing `Replaces`
field worked perfectly for your tests.
Ok, this makes sense.
**However, for users tracking pure Unstable (Sid), there is a gap.**
I currently have `qemu-user-static` version **1:10.0.3+ds-3** installed.
Here is the proof from my system:
$ dpkg -l | grep qemu-user
ii qemu-user 1:10.0.3+ds-3 amd64 QEMU user mode emulation (static binaries)
ii qemu-user-binfmt 1:10.0.3+ds-3 amd64 QEMU user mode binfmt
registration for qemu-user
ii qemu-user-static 1:10.0.3+ds-3 amd64 QEMU user mode emulation
(compat/transitional package)
> The "Replaces" field is meaningless in the context when apt chooses
which version of which package to install. [...] This field is not about
replacing a package, but about replacing *files* within a package.
**This is exactly the problem.**
The new `qemu-user` (and `binfmt` via dependency) attempts to take over
ownership of specific files (like `/usr/bin/qemu-x86_64-static`) that
are currently owned by my installed `qemu-user-static` (1:10.0.3).
There's no conflicting files like this. If there are, it's a bug.
But I still don't see where the actual problem is.
In 10.0 and up, qemu-user and qemu-user-binfmt packages has the same
list of files, - be it 10.0 or 10.2. The only real difference is that
qemu-user-statis is dropped, with all its files. The files which was
in older qemu-user-static are not replaced by any other package, they're
just gone. There is no (or should not be) file conflicts like this.
/usr/bin/qemu-x86_64-static was owned by qemu-user-static before 10.0.3,
and now it does not exist.
1. `dpkg` checks if `qemu-user` has permission to overwrite files owned
by `qemu-user-static` (1:10.0.3).
2. It checks `Replaces: qemu-user-static (<< 1:9.1.0)`.
3. Since **1:10.0.3 > 1:9.1.0**, the condition fails. `dpkg` would
refuse the file overwrite.
4. The APT solver anticipates this file conflict and the lack of a
forceful `Breaks` (which would force removal of the old package),
leading to the dependency error.
ghhhrm.
Maybe you can include the actual logs from apt/dpkg when this problem
happens?
Thanks,
/mjt