On Fri, Jun 12, 2015 at 12:28 AM, Michael Stapelberg <stapelb...@debian.org> wrote: > I’ve spent a bit of time analyzing the dependencies and came up with the > graph you can find attached. There are two leaf packages that can be > immediately tackled, the rest will require tackling the > golang.org/x/net/context packaging situation first.
Thanks for doing this. Question: what would the situation look like if gcsfuse instead 'vendored' its dependencies, so that the exact version it depends on was included in its git repo and it was built with a tool like godep (https://github.com/tools/godep) or nut (https://github.com/jingweno/nut)? It seems like the approach here is laborious and brittle: 1. You have to do work proportional to the number of transitive dependencies of a binary. As an author, I feel bad for depending on several things now. :-) 2. You may have serious issues with versioning if a library changes in a backwards-incompatible way. Compare the homebrew formula for gcsfuse on OS X (https://goo.gl/VrJ5L4), which can't suffer from this problem due to being locked to particular versions that are fetched when building gcsfuse itself. But I think maybe now I'm getting into philosophical territory, especially with (2), which must come up all the time in Debian packaging, even for C programs? Just wondering your thoughts. Aaron _______________________________________________ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
