Package: golang-github-anacrolix-missinggo-dev
Version: 2.1.0-4
Severity: important

Hello Debian Go Packaging Team,

There is a circular dependency between golang-github-anacrolix-missinggo-dev and golang-github-anacrolix-tagflag-dev:

golang-github-anacrolix-missinggo-dev 	:Depends: golang-github-anacrolix-tagflag-dev
golang-github-anacrolix-tagflag-dev 	:Depends: golang-github-anacrolix-missinggo-dev

Circular dependencies are known to cause problems during upgrade between
stable releases, so we should strive to avoid them.

Cheers,

That's correct, the circular dependency is in fact present in the two
packages.

In missinggo,  cmd/filecache/main.go and cmd/http-file-server/main.go
use tagflag.Parse.

In tagflag, parser.go and usage.go use missinggo/slices.

The situation is uncomfortable, but I do not anticipate it will cause
problems in practice.  tagflag is source-only, missinggo only needs it
to be present in the GOPATH, and vice versa.

There is no operational circular dependency in the actual files
involved, i.e. missinggo/slices (required by tagflags) is not the part
of missinggo that depends on tagflags.

missinggo is a collection of various miscellaneous functions, not a
library with a specific capability.  Not all functions are related to
one other.

The alternative is to patch missinggo/slices into tagflag.  This is
easy to do with Go using vendor directories.  This is how I bootstrapped
tagflag.  But now that missinggo itself is available, it doesn't seem
constructive to continue the vendor bootstrap.  It's a worse option
than tolerating the circular dependency, I think.

As discussed above, the circular dependency is an actual part of the
missinggo and tagflag Go modules, but is not expected to cause
problems in practice.

I'll leave this bug open to document the issue, but will tag the bug
"wontfix" (and "confirmed") to indicate that no further action is
required at this point.