On Tue, Feb 14, 2023 at 04:16:33PM -0800, Steve Langasek wrote: >... > working out which of those reverse-dependencies are > *not* scientific applications that should drop the build-dependency rather > than being removed, and so forth. > > So it's a tradeoff between the maintenance work of keeping mpi working on > 32-bit, and the one-time work of removing it. >...
Unfortunately your "one-time work" is not true. Architecture specific differences are not unlikely to cause FTBFS later, e.g. when bumping dh compat changes --list-missing to --fail-missing. Symbols files for shared libraries can be a real pain when there are architecture specific differences that result in different symbols, dropping symbols files for such libraries might be the best option. New dependencies on the packages that are removed/unavailable on some architectures will appear all the time, an example: Some architectures in ports do not have the complete Haskell ecosystem. pandoc is written in Haskell. src:flac builds both a widely used libflac and a rarely used flac command-line program. Upstream of src:flac recently switched from docbook-to-man to using pandoc for generating the manpage for the command-line program. This made the new libflac unavailable on several ports architectures. Someone will have to make the build dependency on pandoc and the contents of debian/flac.install architecture-dependent, or create a separate binary-all flac-common package for the manpage. cu Adrian