On Wed, Feb 15, 2023 at 08:53:13PM +0800, Shengjing Zhu wrote: > On Wed, Feb 15, 2023 at 7:56 PM Adrian Bunk <b...@debian.org> wrote: > > > > On Wed, Feb 15, 2023 at 11:58:54AM +0800, Shengjing Zhu wrote: > > >... > > > The package currently FTBFS on i386/experimental but it won't be problem > > > on > > > unstable. > > > The dep-resolver (aspcud) in experimental chooses gccgo to bootstrap, > > > which has a bug https://github.com/golang/go/issues/51850. > > > But on unstable the dep-resolver is apt, and will choose old golang-go to > > > bootstrap. > > >... > > > > I gave it back on the affected architectures with an extra-depends on > > golang-go, which confirmed that the package builds there. > > > > But relying on resolver behaviour is incredibly fragile, please make > > golang-go the only (or at least the first) alternative in the build > > dependencies. > > In theory gccgo should be able to bootstrap golang-go. >...
That misses my point, which is that when there are several options the package should define and ensure which one is used. Every buildd and every QA build and every build elsewhere should use the same tools for building the package. Otherwise people might end up wasting hours and days trying to understand why a package that built in unstable failed to build somewhere else (in experimental or reproducible builds or in a derivative distribution or elsewhere). Or even worse, if for some reason the package builds but produces different binaries and then someone tries to debug why this happened. That shouldn't happen, but these are absolutely nasty and time-consuming bugs. > Shengjing Zhu cu Adrian
