[pkg-go] golang-google-cloud and other breakage

[Potter, Tim]

On 5 Jan 2017, at 6:34 PM, Martín Ferrari <tincho at tincho.org> wrote:
> 
> Tim,
> 
> On 04/01/17 02:28, Potter, Tim wrote:
>> I was poking at this last year before Christmas and grpc is actually up to
>> SupportPackageIsVersion4 now.  )-:
> 
> Yes. This was indeed the issue. Packages including pre-generated
> protobuf go filess, were using the older symbols. So these packages were
> not building any more.
> 
>> Should be make it a general policy to regenerate proto files for each new
>> grpc release?  This sounded good to me until I discovered that etcd3 has
>> the grpc as an official API[1],[2].  I think that I saw the etcd.proto file (for etcd2)
>> in the source of another package (swarmkit?).  Not sure whether the version
>> business is going to mess is up here as well - are the wire formats incompatible
>> between the different versions?
> 
> I don't think the wire formats are incompatible, but I haven't checked.

I believe that backwards compatibility is possible at both the protobuf and grpc
levels by design but requires some knowledge and forethought by the developer.
It may Just Work but yeah more research is required.

I found this article about Python protobuf version issues which might map
across to golang:

http://wtanaka.com/node/8203

> In my opinion, no package should be shipping .pg.go files from upstream.
> Instead, we should re-generate those at build time, using the current
> versions of protobuf-compiler and grpc. So, next time there is an
> incompatible change, we only need to rebuild the libraries that generate
> .pb.go files.

I remember regenerating .pb.go files for one package but not at build time so it's
probably broken again now.  Build-time sounds like the most Debian-ish way to
do things.

>> I think I decided that vendoring the source for grpc in each package where it's
>> needed was going to be easier.  The Debian way of having a single source
>> for a library is not really working here.
> 
> I honestly don't like that. I understand we vendor sometimes when there
> is no other option, or the extra work is too much. But in this case, we
> only need to fix the package once.
> 
> In the future, we should also start versioning grpc and
> protobuf-compiler, so we can detect this automatically.

Hmm - also a good idea.  A problem would be that I don't think that bug and security
patches are not backported to old release, but that's no worse than what we have
at the moment.

So your proposal is to do both of regenerate .pb.go files at build time and version
the grpc package with the SupportPackageIsVersionX number?  Sounds good to
me but a lot of work.  (-:


Tim.

> 
> 
> --
> Martín Ferrari (Tincho)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20170105/fc580772/attachment.sig>