Comment 1 for bug 1957932

Thanks for working on this Simon!

On the testing front, I think this is just pragmatism. There are always a few failing tests for not very interesting reasons, and a few more on !amd64. Debian does something slightly different and asserts no more than a certain (per-architecture) number of test cases fail. If we have the resources to look into these and patch out the tests we don't care about and try to file bugs upstream and generally stay on top of the situation, I think this would be a good thing. But the long turnaround in build times for rustc would make this a very tedious process. Maybe we can set up some CI or something.

Another point that's worth bearing in mind is that up to now the main point of maintaining the packages at all has been to deliver updates to firefox in LTS releases, so they have always been maintained with more of an eye to an easy stable update than being a good citizen in the devel series (this is what motivates the bundling of llvm, in particular). It would be reasonably easy to not vendor llvm in the devel series I think (although this would require us to be more aggressive about moving new versions of llvm to main I suspect).

I don't really understand why Debian separates the rustc and cargo source packages. I think we should consider not doing that, and in general doing things more the upstream way and not the Debian way (although not completely: I think upstream bundles the openssl source for example!).

A rustc autopkgtest that ensures rustc can build itself would be a good thing to have. We had a bug that prevented rustc from building itself on s390x get through to release once and re-bootstrapping to get out of this situation is painful.