Packaging Kubernetes for Debian

I'm, reluctantly, inclined to agree. I don't have much experience on the Debian side of things, but I've written a few Guix packages, and Guix has similar requirements, so I'll speak to that a bit.

Distros like Guix have good reasons to want all packages to be packaged in Guix itself; for one, it allows them to more tightly constrain the build environment, which goes a long way towards ensuring reproducibility. Packages can't reach out to the internet during builds for example, which eliminates a big potential source of nondeterminism.

But that said... the Go package model just does not match up cleanly with the distro package model. As you mention, Go keeps the hashes of dependencies around, and there are quite a few dependencies - enough to make manually packaging all of them, with all the different versions required by different applications, a gargantuan task.

Go builds (unlike those in many other languages) are reproducible on their own, even without sophisticated package managers. And even if Debian starts packaging individual Go libraries, Go developers aren't likely to start using the versions shipped with Debian - it goes against the grain of what their language tooling expects. I'm inclined to think that distros in this particular case should step aside and let the language tooling do its job; or possibly, in Guix's case, to more tightly integrate with the language tooling, because Go's build system has a lot of the same goals that Guix's does. Distro packagers will simply not be able to keep up otherwise for any package with a nontrivial number of dependencies, and that's a lot of them these days.

That may have been true a few years ago, but along the same timescales of the inclusion of the JS and Go ecosystems has come much better tooling around automatic rebuilds of reverse dependencies. In particular, autopkgtest gives greater confidence that something not just compiles but actually functions correctly once installed.

https://release.debian.org/doc/britney/solutions-to-commo...

As a user, I like the ability to install and update my go binaries in the same way that I update the other binaries on my system.

The current overhead for creating a new package is significant if you have to manually package a lot of dependencies (such as for Kubernetes). Debian has certain assumptions about how much human-customized packaging overhead each package needs, and in the past that overhead was acceptable - shared libraries in e.g. the C world tend to be larger and less predictable.

For many of the newer ecosystems (go, rust, haskell, node) packages could be generated with a lot less overhead, because . The approach taken by the rust team with debcargo is promising - the overhead for adding an extra package is minimal, and makes it easy to add many more packages. See for example https://salsa.debian.org/rust-team/debcargo-conf/-/tree/m...