Re: OpenMPI 5.0 to be 32-bit only ?
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
Reply to: