On 03/03/2026 13:47, Richard Hansen wrote:
golang.org/x/net and golang.org/x/crypto require each other in their go.mod files, but I noticed that the golang-golang-x-crypto-dev Debian package contains a copy of the golang.org/x/net/idna Go package to break that dependency cycle: <https://salsa.debian.org/go-team/packages/golang-go.crypto/-/blob/debian/latest/debian/README.source>.
One issue with circular dependencies is when you want to update the packages to newer version.
Like, you try to bump x/net, but find out it FTFBS because it needs a more recent x/crypto. So you try to update x/crypto first, but it FTBFS because it needs a more recent x/net. Now you're stuck, and untangling this might be tricky and _really_ time-consuming.
I learnt that the hard way with the docker stack years ago. I don't know if it ever happened in practice with golang.org/x/{net,crypto}.
I'd think a little code vendoring can be better than a circular dependency. In this particular case, the maintainer of this package knows best.
Cheers, Arnaud
