Re: Truncated changelog leads to file conflict with MultiArch: same

On 17/05/26 11:58, Dominique Dumont wrote:
> Mulitarch hinter mentions:
> 
>   There are issues with the multiarch metadata for this package.
> 
>      libisoburn-dev conflicts on /usr/share/doc/libisoburn-dev/changelog.Debian.gz on loong64 <-> amd64, arm64, armhf and 4 more
>      libisoburn1t64 conflicts on /usr/share/doc/libisoburn1t64/changelog.Debian.gz on loong64 <-> amd64, arm64, armhf and 4 more
> 
> As suggested by the wiki page, I've downloaded and compared loong64 and amd64 binary packages.
> 
> Turns out that both have a truncated changelog. But the loong64 package has less entries.

Hi, the issue you are seeing is due to the fact that the loong64 buildd 
chroot has (had) a newer version of debhelper compared to the one used 
in the other archs.

Here is an edited version of what I said on #debian-devel a few days ago 
when the same issue has been described there:

* The newer debhelper has a new cutoff date for the changelog trimming 
function of dh_install_changelogs, so the generated changelogs may be 
different.

* This is issue is a special case of "use of different package versions 
in different buildd chroots". If the amd64 buildd chroot has a program 
that generates a file in /usr/share (say, pod2man) at version X and the 
loong64 has version X+1, then the generated file (a manpage, for 
example) may/will be slightly different.

* pod2man is just an example. What must not change between two binNMUs 
is the sum of all packages that are used to produce files that can cause 
M-A problems. The list is long (pod2man, texinfo, sphinx, doxygen, 
pandoc...) but luckily they are updated quite seldomly.

* The only solution to this problem is that 1) all buildd chroots must 
be updated at the same time, and 2) all binNMU must run inside the same 
dinstall window. Otherwise there will always be the risk of package 
version skew and M-A issues.

Regards,