Bug#1133748: 6 packages from scotch fail to coinstall
Helmut Grohne
helmut at subdivi.de
Sat May 2 15:26:46 BST 2026
Control: tags -1 - moreinfo
Hi Drew,
On Sat, May 02, 2026 at 01:56:47PM +0200, Drew Parsons wrote:
> Helmut, file clash bug reports like this need to give more detail or
> at least more context. Otherwise it's trying to find a needle in a
> haystack second guessing where the clash happened.
Really? Let's try figuring this out. The simplest of those packages
probably is libscotch-dev. The simplest of architecture combinations
probably is amd64 and i386. Download both packages, diff the filename at
hand.
--- amd64/usr/include/scotch/scotch.h 2026-02-25 14:34:20.000000000 +0100
+++ i386/usr/include/scotch/scotch.h 2026-02-25 14:34:20.000000000 +0100
@@ -137,7 +137,7 @@
#endif /* LIB_SCOTCH_H_UNIQUE */
typedef struct {
- double dummy[11];
+ double dummy[6];
} SCOTCH_Arch;
typedef struct {
@@ -145,27 +145,27 @@
} SCOTCH_ArchDom;
typedef struct {
- double dummy[3];
+ double dummy[2];
} SCOTCH_Context;
typedef struct {
- double dummy[2];
+ double dummy[1];
} SCOTCH_Geom;
typedef struct {
- double dummy[12];
+ double dummy[8];
} SCOTCH_Graph;
typedef struct {
- double dummy[15];
+ double dummy[10];
} SCOTCH_Mesh;
typedef struct {
- double dummy[4];
+ double dummy[2];
} SCOTCH_Mapping;
typedef struct {
- double dummy[17];
+ double dummy[11];
} SCOTCH_Ordering;
typedef struct {
None of this involved much guesswork. Why do you compare this to
searching a needle in a haystack? What I consider finding a needle in a
haystack is taking this diff and figuring out what caused these numbers
to change.
I suggest tackling this one instance and hoping that all the others are
of the same kind. If conflicts remains, I can file a new bug.
> The files involved are identified, but not the actual clash.
As we see, this is easily identified.
> These headers files don't reference the arch directly, so it's not as
> simple as an embedded <multiarch> reference.
Correct.
> The reporting tool found some file clash, but where exactly?
It actually does not know. It only retains a checksum of the contents
and concludes that when checksums differ, so does the content. If it
were including the difference, the resulting mails would become huge.
The balance is difficult to strike and given how easy it is to identify
the differences, I opted for not including them in the report.
> Is the clash between all architectures or only some architectures?
They're all different, yes.
> The tool identified a clash exists. It would be helpful to know where
> it found the clash. Best would be a diff (or even a partial diff) of
> one or more of the files. But if a file diff is not feasible, even
> knowing how the clash was identified would be helpful.
I think the diffing is easy, but the diff result can be binary or huge
or both. Hence putting it into a mail looks infeasible to me. Maybe the
answer where is providing a script (e.g. via devscripts) that developers
might point at a binary package name they suspect (or were told) to have
conflicts and it would generate all those diffs on your local system.
Would you find that appropriate?
> The tool is automated, but it's not communicating sufficient
> information automatically to be able to take action.
It is partially automated. I am vetting each individual report and
editing many of them to further compress the report and/or provide
additional information. In this case, the available information looked
(and still looks) sufficient to me.
> How does the tool know there is a clash? The tool should report what
> it knows.
Would you like it to include per-arch checksums of affected files?
> Even knowing which architectures are involved would be helpful.
I was working on that, but didn't find good solutions to this yet. In
effect, I am observing a relation on architectures expressing what
combinations are incompatible despite being declared M-A:same. This
relation is symmetric and irreflexive, but not transitive. How do I
sensibly convey such a relation to a user? I welcome ideas.
Helmut
More information about the debian-science-maintainers
mailing list