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

[Michael Stapelberg]

The remaining packages are:

golang-github-jacobsa-bazilfuse (currently in NEW)
golang-github-jacobsa-fuse
golang-github-jacobsa-gcloud
gcsfuse

Where each one depends on the one before being accepted into Debian. The
packaging itself is done, it’s now just a matter of waiting for ftpmaster
to accept them one by one.

On Mon, Jun 22, 2015 at 10:00 AM, Michael Stapelberg <stapelberg at debian.org>
wrote:

> I’m a bit pressed on time, so short reply: See
> https://qa.debian.org/developer.php?login=stapelberg%40debian.org for
> which packages are in Debian and which ones are in NEW.
>
> Currently, all further packages are blocked on golang-golang-x-sys getting
> accepted.
>
> paultag, can you help with that? :)
>
> On Mon, Jun 22, 2015 at 3:34 AM, Aaron Jacobs <jacobsa at google.com> wrote:
>
>> Hi Michael,
>>
>> Any progress with the remaining packages? Feel free to ignore my
>> philosophical
>> questions/suggestions if they're not relevant or helpful.
>>
>> Aaron
>>
>> On Mon, Jun 15, 2015 at 8:32 AM, Aaron Jacobs <jacobsa at google.com> wrote:
>> > On Fri, Jun 12, 2015 at 5:02 PM, Michael Stapelberg
>> > <stapelberg at debian.org> wrote:
>> >> 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).
>> >
>> > I agree it's the convention to never break backwards compatibility, but
>> it does
>> > happen from time to time. I will sheepishly raise my hand and say that
>> I've
>> > done it, and will probably do it again, for code that I own where other
>> code I
>> > own is the primary or sole user.
>> >
>> > In such a case, would bumping a major semantic version number (in the
>> form of a
>> > git tag) help you? I guess this would be the analog of C library
>> versions, but
>> > I don't actually know how Debian deals with the problem of dependent A
>> needing
>> > version 1 and dependent B needing version 2, even for C libraries.
>> >
>> >
>> > On Mon, Jun 15, 2015 at 7:13 AM, Michael Stapelberg
>> > <stapelberg at debian.org> > 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
>> >
>> > Great! Thank you. :-)
>> >
>> >
>> >> 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.
>> >
>> > I had been feeling guilty I hadn't done this anyway; thanks for the
>> push. Done:
>> >
>> >     https://github.com/jacobsa/timeutil
>> >     https://github.com/jacobsa/syncutil
>>
>
>
>
> --
> Best regards,
> Michael
>



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