[Pkg-rust-maintainers] Bug#1040477: librust-syn-1-dev fails to coinstall

[Helmut Grohne]

Hi Peter and Fabian,

On Thu, Jul 06, 2023 at 01:27:19PM +0200, Helmut Grohne wrote:
> Package: librust-syn-1-dev
> Version: 1.0.109-2
> Severity: serious
> Justification: fails to (co)install
> Control: affects -1 + src:rust-fd-find
> User: debian-cross at lists.debian.org
> Usertags: ftcbfs
> X-Debbugs-Cc: deity at lists.debian.org
> 
> librust-syn-1-dev has (among other things) the following metadata:
> 
> Provides: librust-syn-1.0.109-dev
> Breaks: librust-syn-1.0.109-dev
> Multi-Arch: same
> 
> It is not clear to me what this is supposed to mean. Can you shed some
> light on what this is supposed to achieve?
> 
> In any case, apt and dpkg disagree about what this shall mean. apt
> thinks that self-breaks are to be ignored and asks dpkg to configure
> both of these packages, but dpkg doesn't like that:
> 
> | dpkg: dependency problems prevent configuration of librust-syn-1-dev:amd64:
> |  librust-syn-1-dev:arm64 (1.0.109-2) breaks librust-syn-1.0.109-dev and is unpacked but not configured.
> |   librust-syn-1-dev:amd64 (1.0.109-2) provides librust-syn-1.0.109-dev.
> | 
> | dpkg: error processing package librust-syn-1-dev:amd64 (--configure):
> |  dependency problems - leaving unconfigured
> 
> You can reproduce the installation failure using:
> 
> mmdebstrap unstable /dev/null --architectures=amd64,arm64 --variant=apt --include=librust-syn-1-dev:amd64,librust-syn-1-dev:arm64
> 
> If apt and dose were refusing this situation this were a normal bug at
> best. But since dpkg fails badly and leaves the system in an
> inconsistent state, I am raising this to rc-severity. Even if we deem
> this to be an apt bug or dpkg bug in the end, librust-syn-1-dev must
> still be changed since we cannot depend on fixed versions of package
> managers being used to install packages.

This problem, which is reported almost a month ago still persists. I am
aware that a generic solution is hard to come by and I need to be
patient for a full solution.

On the flip side, the current metadata causes dpkg and dose to disagree.
This in turn causes https://crossqa.debian.net to believe that there is
a temporary problem with the archive as a whole. It thus ceases testing
further packages until the next mirror push. This behaviour is very
useful in cases where there are M-A:same skews as those tend to affect
very many packages. Since rust-syn appears in more and more packages
Build-Depends, this particular bug effectively disableds cross
compilation testing now as crossqa.d.n tests a few packages until it
runs into an affected one and throttles itself. Is there any chance we
could have a temporary workaround for this issue?

A very simple workaround from my pov would be temporarily removing
Multi-Arch: same. Of course that would make the package unavailable to
cross compilation, but on the flip side, it already is. After dropping
Multi-Arch: same, dose would no longer consider solutions involving
coinstallations of it and archive testing could continue.

Failing that, the only way I see is blacklisting the package in crossqa,
but then I'd probably forget about it and it would also be surprising in
the diagnostics as crossqa would always tell that this package does not
exist. I prefer having you work around the issue. A simple upload
dropping M-A:same removes the worst of pain and gives us time to work on
a generic solution. Do you agree?

Helmut