The file /usr/include/utf8 is contained in the packages
 * libutf8.h-dev/0.0~git20231220.535001e-2 as present in trixie|unstable
 * libutfcpp-dev/4.0.5-1 as present in trixie|unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Please figure out which of these packages should properly own the
affected file and reassign the bug as appropriate. When doing so, please
add the other package to the set of affected packages using "Control:
affects -1 + <packagename>" to avoid the filing of duplicates.

The other package should stop installing the file. In case the file is
being moved between packages, Breaks and Replaces should be declared. In
this case, please refer to policy section 7.6 for details. Another
useful resource is https://wiki.debian.org/PackageTransition.

Kind regards

Helmut

Hi Boyuan,

You have introduced the /usr/include/utf8 link in libutfcpp-dev, which
was after libutf8.h-dev already had that directory. Your changelog entry
says:

  * debian/libutfcpp-dev.maintscript, debian/libutfcpp-dev.links: Add
    compat symlink to avoid breaking build-dependencies after upstream
    moved header file paths.

Do you remember which packages were affected?

Thanks,
Bastian

Hi,

在 5/15/2025 9:46 AM, Bastian Germann 写道:

It has been a while and I don't remember it, sorry. Going
through reverse-build-dep list with rebuilds might be the best way
of finding out.

Thanks,
Boyuan

Even though libutf8.h-dev was the first to have this path in the
installed files, I suggest to modify libutf8.h-dev because it is not
used by any other Debian package and can easily change its file paths.

Please find a patch attached that installs the header file to a
different location.

Control: reassign -1 libutf8.h-dev

Given this is the case, libutf8.h-dev being removed from testing and
we need libutfcpp-dev to exist in testing, I'm reassigning the bug
away from libutfcpp-dev.

Potentially, if no users of utf8.h show up, removal might also be a
valid solution.

Chris