Richard Hansen <[email protected]> writes: > Hi all, > > Is it a problem to have a Depends cycle among the golang-*-dev packages? > > 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>. > > I thought dpkg could handle circular dependencies. Would a cycle > cause FTBFS? Can an older version of the package being built be > installed to satisfy the circular dependency while building the newer > version of the package?
Debian policy says this (search for 'cycl' on the page): https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends Cyclic dependencies complicate bootstrapping a new arch and cross-compiling too, I think, but I suspect that for golang-* packages without postinst scripts, it will just work fine. Having an earlier version of the same package installed during build is confusing to debug, and you always worry that somehow things from the earlier package version will be used instead of the source code from the latest package. Maybe golang.org/x/net and golang.org/x/crypto aren't in any early Debian bootstrap or cross-compile today, but it doesn't seem unlikely that they will be in the future when the Go ecosystem becomes more integrated into Debian, like Rust has become recently. One improvement to golang-go.crypto may be to NOT ship the vendored IDNA files in the resulting *.deb. Nobody else should rely on those vendored files being present in the installed package, should they? So instead it could copy debian/go/src/golang.org/x/net/idna/ to usr/share/gocode/src/golang.org/x/net/idna/ during build of golang-crypto. What do you think? Maybe the self-tests needs to be modified somewhat. The binary golang-golang-x-crypto-dev package could Depends: on golang-golang-x-net-dev, that shouldn't cause any problem, should it? OTOH, I don't know what problem all this really solve, it just looks nicer. So maybe not worth it. /Simon
signature.asc
Description: PGP signature
