On Mon, 18 May 2020 at 12:45, Helmut Grohne <[email protected]> wrote: > On Mon, May 18, 2020 at 09:53:04AM -0700, Tianon Gravi wrote: > > I'm curious though, is there a technical reason we need so many extra > > binary packages, especially when each binary package amounts to > > essentially a single very short shell script? Couldn't we instead > > package them all together into one binary package, something like > > "golang-go-multiarch-wrappers" ? > > We could try fusing the golang-go-<triplet> either into > golang-go-for-host or into a shared golang-go-multiarch-wrappers. If we > try the former, golang-go-for-host would have to depend on a native > golang-go. My patch expresses that by going via arch:all m-a:foreign > packages. The golang-go-for-host -> golang-go-<triplet> dependency > looses its architecture constraint due to Multi-Arch: foreign. If > golang-go-for-host were to depend on golang-go directly, we'd have to > make it Multi-Arch: foreign or we'd have to make it Multi-Arch: allowed > and annotate the dependency with :any. The outcome of that isn't > obvious. > > So the other way would be golang-go-multiarch-wrappers. Unlike with gcc, > this is actually feasible, because we know the available targets ahead > of time. We cannot retroactively add architectures without rebuilding > all of go. So that actually works. It just didn't occur to me any > earlier. I'd prefer to have this package provide all the > golang-go-<triplet> instances as virtual packages though. > > Another issue with fusing into golang-go-for-host (but not the other > way) is that it requires adding the relevant target architecture using > dpkg --add-architecture. > > A weak argument is consistency with gccgo. This is precisely the layout > that gccgo uses (except that gccgo uses Arch:any packages instead of > Arch:all). Keeping this layout as virtual packages seems sensible > though. > > So yeah, I think it's actually possible to fuse them into a > golang-go-multiarch-wrappers package. Let me propose a different name > though: golang-go-for-build. That way it'd precisely mirrors what we do > for binutils already and what we will be doing for the gcc frontends.
Looking at this again, and I'm kind of concerned by how similar this new script is to https://salsa.debian.org/go-team/compiler/golang/-/blob/0b1574525525719281c84cfa55ec7ca7719be8d9/debian/helpers/goenv.sh which we already maintain in the compiler packages -- I bet there's some way we could make either the new script work for the bootstrapping use case or better would be the other way around? That raises the question of which source package the script should live in. 🤔 I think it would be pretty reasonable/easy to split that script into "things we need to set for bootstrapping" and "things we need to set for cross-building with Go", especially given I just removed a bunch of bootstrap-specific logic from it in my latest touching of it (while making src:golang-X.Y itself cross-buildable). Maybe it does make sense to have a variant of that script that lives in every src:golang-X.Y? I don't know, because there's very little in it right now that's specific to a particular version of Go (although it *has* had to have complicated logic that in the past, like when the value for GO386 had to change, and getting it right across the bootstrapping boundary was extra complicated). Personally, I'm not very convinced by any gccgo compatibility, especially since I don't think gccgo has kept/reasonably can keep up with modern Go versions very well (and in the meantime, Go has gotten better at officially supporting all the architectures we might care about for which we used to lean on gccgo). As evidence, gcc-15 appears to still contain Go 1.18 (since gcc-12, in fact), but also apparently doesn't support generics so it's not really quite 1.18. 😬 I think it's probably not even enough to be a sufficient bootstrapper for Go itself anymore, but I haven't checked that recently. I also need to admit that I don't actually understand the need for so many explicit package names -- is there some existing convention that will automatically install the correct package based on existing Build-Depends or something that warrants all this extra complexity? ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
