On 23/04/2023 19:19, Paul Gevers wrote:
I claim this is wrong. Would python3-sage one day build on more
architectures, this list would need manual updating. Instead of
hard-coding the list, it's better to ensure the build doesn't happen
or fails on architectures where python3-sage is not available. E.g. by
build-depending (ideally with a build profile indicating that the
*build* itself works; I suggest <!nocheck>).
That works in some cases, but it's a bad option here for two reasons.
1. It would create a build-dependency loop between brial and sagemath.
2. It would mean that other binary packages built from the brial source
package had their architecture list unnecessarily limited.
> Technically I even think that this isn't a bug in python3-brial.
One of the criteria (indeed the first on the list) for grave is "makes
the package in question unusable or mostly so". I consider that a
package that cannot be installed is unusable.
My understanding has always been that for source packages that build
multiple binaries, the test of "is the package unusable" is applied for
each binary package individually and that for packages that are built
separately for multiple architectures (not arch all packages) it is
applied for each architecture individually. I don't think that is
officially written down anywhere though.
This seems to be your real issue. Why file the bug against python3-brial?
When an issue involving multiple packages shows up on my radar, I tend
to start by filing a bug with the package where a fix could potentially
have the most impact and cc the maintainers of other packages that are
involved.
If the maintainer of brial came back and said that the fix for bug
1033878 was wrong, and that python3-brial could in-fact be made usable
on all architectures then there would.
On the other hand whatever changes were made in singular we would still
have unusable python3-brial packages.
So I started out with a bug against python3-brial.
