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

Michael Stapelberg stapelberg at debian.org
Fri Jun 12 07:02:14 UTC 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20150612/6b0cf59c/attachment.html>


More information about the Pkg-go-maintainers mailing list