Status update: golang-github-jacobsa-oglematchers is in Debian golang-github-jacobsa-reqtrace is in Debian golang-goprotobuf was updated in Debian
golang-github-jacobsa-oglemock is in the NEW queue golang-github-jacobsa-ogletest is in the NEW queue golang-google-appengine is in the NEW queue golang-golang-x-oauth2 is in the NEW queue Looking at remaining dependencies, you could save me a lot of headaches if you could split out github.com/googlecloudplatform/gcsfuse/timeutil into a separate repository. Otherwise, we have circular dependencies ( github.com/googlecloudplatform/gcsfuse depends on github.com/jacobsa/fuse, which depends on github.com/googlecloudplatform/gcsfuse/timeutil). Also, either doing the same with github.com/jacobsa/gcloud/syncutil or inlining the (github.com/jacobsa/fuse/fsutil).AnonymousFile call in github.com/jacobsa/gcloud/gcs/tools/gcsthroughput/gcsthroughput.go would help as well. On Fri, Jun 12, 2015 at 9:02 AM, Michael Stapelberg <[email protected]> wrote: > The situation would actually be worse, because then I would need to delete > the vendored copies in the build process and still do the same work :). > > The Debian policy is to not ship copies of libraries in packages. For C, > that works quite well, since library authors are generally aware of SONAMEs > and when they need to bump them. For Go, package paths are supposed to > never break backwards compatibility, and it seems like most of the > community agrees. We haven’t had a single case of backwards compatibility > breakage yet (that I know of). > > On Fri, Jun 12, 2015 at 1:12 AM, Aaron Jacobs <[email protected]> wrote: > >> On Fri, Jun 12, 2015 at 12:28 AM, Michael Stapelberg >> <[email protected]> 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 >> > > > > -- > Best regards, > Michael > -- Best regards, Michael
_______________________________________________ Pkg-go-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
