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

Reply via email to