Hi, > How about packaging a superset from the author (go-exif-knife) which > includes all the other tiny packages, and is a more useful standalone > program. Further, also publishing the vendored sources as binary -dev > packages for any future users (and d2 as well). > That means the binary name is taken, so no future duplicates or > conflicts in the archive. > > That approach along with documenting the "circular dependency" in > README.source, do you think raises the chances ftpmasters will accept it?
Sounds reasonable if you think go-exif-knife is a good "unit" to bundle these in. If any of the vendored stuff grows and starts its own life, they can always be split out into separate packages. The NodeJS team does a lot of git-buildpackage component + watch file multipart structures (example https://salsa.debian.org/js-team/node-gyp/-/blob/master/debian/gbp.conf), but as Jeremy wrote we can't do it yet as uscan lacks ctype=go that actually reads go.mod and makes sure those dependencies are of correct version automatically. Also I think the structure is a bit overengineered with assumptions about frequent updates that most of the time are not there.
