<div dir="ltr">Status update:<div><br></div><div>golang-github-jacobsa-oglematchers is in Debian<br></div><div>golang-github-jacobsa-reqtrace is in Debian<br></div><div>golang-goprotobuf was updated in Debian<br></div><div><br></div><div><div>golang-github-jacobsa-oglemock is in the NEW queue</div></div><div>golang-github-jacobsa-ogletest is in the NEW queue<br></div><div>golang-google-appengine is in the NEW queue<br></div><div>golang-golang-x-oauth2 is in the NEW queue<br></div><div><br></div><div>Looking at remaining dependencies, you could save me a lot of headaches if you could split out <a href="http://github.com/googlecloudplatform/gcsfuse/timeutil" target="_blank">github.com/googlecloudplatform/gcsfuse/timeutil</a> into a separate repository. Otherwise, we have circular dependencies (<a href="http://github.com/googlecloudplatform/gcsfuse" target="_blank">github.com/googlecloudplatform/gcsfuse</a> depends on <a href="http://github.com/jacobsa/fuse" target="_blank">github.com/jacobsa/fuse</a>, which depends on <a href="http://github.com/googlecloudplatform/gcsfuse/timeutil" target="_blank">github.com/googlecloudplatform/gcsfuse/timeutil</a>).</div><div><br></div><div>Also, either doing the same with <a href="http://github.com/jacobsa/gcloud/syncutil" target="_blank">github.com/jacobsa/gcloud/syncutil</a> or inlining the (<a href="http://github.com/jacobsa/fuse/fsutil).AnonymousFile" target="_blank">github.com/jacobsa/fuse/fsutil).AnonymousFile</a> call in <a href="http://github.com/jacobsa/gcloud/gcs/tools/gcsthroughput/gcsthroughput.go" target="_blank">github.com/jacobsa/gcloud/gcs/tools/gcsthroughput/gcsthroughput.go</a> would help as well.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 12, 2015 at 9:02 AM, Michael Stapelberg <span dir="ltr"><<a href="mailto:stapelberg@debian.org" target="_blank">stapelberg@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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 :).<div><br></div><div>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).<br><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Fri, Jun 12, 2015 at 1:12 AM, Aaron Jacobs <span dir="ltr"><<a href="mailto:jacobsa@google.com" target="_blank">jacobsa@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Fri, Jun 12, 2015 at 12:28 AM, Michael Stapelberg<br>
<<a href="mailto:stapelberg@debian.org" target="_blank">stapelberg@debian.org</a>> wrote:<br>
> I’ve spent a bit of time analyzing the dependencies and came up with the<br>
> graph you can find attached. There are two leaf packages that can be<br>
> immediately tackled, the rest will require tackling the<br>
> <a href="http://golang.org/x/net/context" target="_blank">golang.org/x/net/context</a> packaging situation first.<br>
<br>
</span>Thanks for doing this.<br>
<br>
Question: what would the situation look like if gcsfuse instead 'vendored' its<br>
dependencies, so that the exact version it depends on was included in its git<br>
repo and it was built with a tool like godep (<a href="https://github.com/tools/godep" target="_blank">https://github.com/tools/godep</a>)<br>
or nut (<a href="https://github.com/jingweno/nut" target="_blank">https://github.com/jingweno/nut</a>)?<br>
<br>
It seems like the approach here is laborious and brittle:<br>
<br>
1. You have to do work proportional to the number of transitive dependencies of<br>
a binary. As an author, I feel bad for depending on several things now. :-)<br>
<br>
2. You may have serious issues with versioning if a library changes in a<br>
backwards-incompatible way. Compare the homebrew formula for gcsfuse on OS X<br>
(<a href="https://goo.gl/VrJ5L4" target="_blank">https://goo.gl/VrJ5L4</a>), which can't suffer from this problem due to being<br>
locked to particular versions that are fetched when building gcsfuse itself.<br>
<br>
But I think maybe now I'm getting into philosophical territory, especially with<br>
(2), which must come up all the time in Debian packaging, even for C programs?<br>
<br>
Just wondering your thoughts.<br>
<span><font color="#888888"><br>
Aaron<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div>Best regards,<br>Michael</div>
</font></span></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Best regards,<br>Michael</div>
</div></div>