On Fri, Oct 23, 2026 at 08:06:20AM +0200, Andreas Tille wrote: > Hi, Hi Andreas,
> Am Mon, Oct 05, 2026 at 03:21:01AM +0300 schrieb Adrian Bunk: > > > https://gitlab.com/petsc/petsc/-/work_items/1881 > > > > Since we are hitting the problem again, could you add something like the > > attached patch? > > Thank you Adrian for the patch. > > I wonder whether we could circumvent this kind of trouble by adding > architecture-is-64-bit to Build-Depends. This would mean we need to > ask for removal of quite a number of binary packages, thought. I wonder if people could stop this kind of architecture restriction trouble by trying to understand problems first instead of blindly adding architecture-is-64-bit. architecture-is-64-bit is not a solution for a normal bug. The OpenMPI part of this bug could even be "solved" with architecture-is-32-bit (sic). It puzzles me how people even start considering adding architecture-is-64-bit when nothing in a bug hints at an unsolvable 32-bit issue. This bug is a case of a runtime check not matching the package dependencies, and either of these has to be fixed. > But in the end I think this is no practical restriction for our users > and we might get rid of some maintenance burden. Architecture restrictions are also a maintenance burden. When you go through the transitive rdeps of petsc, you will e.g. realize that adding architecture-is-64-bit would force octave to hardcode and maintain a manual architecture list in its sundials build dependency. And then you have different functionality of octave on different architectures, which could result in follow-up build or runtime issues. > Kind regards > Andreas. cu Adrian
