[pkg-go] gcsfuse -- fuse file system for Google Cloud Storage

[Michael Stapelberg]

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 <stapelberg at debian.org>
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 <jacobsa at google.com> wrote:
>
>> On Fri, Jun 12, 2015 at 12:28 AM, Michael Stapelberg
>> <stapelberg at 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
>>
>
>
>
> --
> Best regards,
> Michael
>



-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20150614/dded0104/attachment-0001.html>