Bug#1030957: release.debian.org: please have rust-rustls ignore CI tests for s390x and ppc64el
On Fri, Feb 10, 2023 at 03:10:03PM -0700, Sam Hartman wrote:
> >>>>> "Jonas" == Jonas Smedegaard <dr@jones.dk> writes:
>
>
> Jonas> Yes, I am aware that the Rust team packages arch-all code as
> Jonas> arch-any packages, but I am unaware that their reasoning is
> Jonas> well documented anywhere. The only reason I was aware of
> Jonas> when I did the switch was that Debian has a convenient
> Jonas> processing of binNMUs but annoyingly require source-only
> Jonas> releases for rebuilding arch-all packages.
>
> But the bin nmu issue is a huge deal. I'm not sure for your case. But
> Rust is statically linked, and so it is more likely than average to need
> bin nmus. So if your packages will need to be rebuilt when their
> dependencies change (I am not sure if this is true for packages just
> containing crate source code), then moving from arch any to arch all
> makes things significantly more difficult for SRM, RT, security team,
> and people doing QA woork.
> I'd definitely recommend reaching out to Adrian Bunk on this issue.
Built-Using in binary-all packages is a problem.
Extra-Source-Only means we might even have our mirrors serve sources
that were removed from unstable years ago due to "not distributable".
No matter whether or not Built-Using is used (which should only be used
for licence compliance), the rebuild question might come up for
binary-all packages that contain binaries for an architecture that
is encoded in the package name (e.g. cross compiler libraries or
microcontroller firmware like firmware-microbit-micropython).
There are rare cases where binary-all python packages have to be rebuilt
during every python transition, e.g. scripts that start with
#!/usr/bin/python3.11
And then there's the special PITA of the gcc-*-cross* packages that
also make invalid assumptions like that the binary-any packages are not built
after the binary-all packages from the same source package (otherwise
the binary-any packages might have dependencies that cannot be fulfilled).
None of the above seems to apply to the package in question.
There is the real problem that all binaries that have been built using
rust-rustls might need rebuilding in security or stable when rust-rustls
gets a security or other important fix, but for that it does not make
any difference whether librust-rustls-dev is binary-any or binary-all.
> If on the other hand your packages aren't going to need to be rebuilt
> when their dependencies change, it may not be a big deal.
I would be curious whether there is any technical reason why most
Go libraries are binary-all but most Rust libraries are binary-any.
Both choices look reasonable to me, but different ecosystems in Debian
seem to have made different decisions in the same situation.
cu
Adrian
Reply to: