Re: Dealing with circular dependencies
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.
Reply to: