On Fri, Feb 10, 2023 at 03:10:03PM -0700, Sam Hartman wrote: > >>>>> "Jonas" == Jonas Smedegaard <d...@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
