On 21/03/16 00:05, Zac Medico wrote: > On 03/20/2016 11:45 PM, Andrew Udvare wrote: >> https://github.com/google/google-api-go-client/ >> >> Looking at these to generate ebuilds for (with a script and GitHub API). >> There might be an issue with assuming versions supersede (otherwise why >> would they keep multiple versions up?). > > Can you clarify which versions you're talking about? We shouldn't slot > it if the new versions are backward compatible.
The version numbers are the packages like: google.golang.org/api/adexchangebuyer/v1.2 google.golang.org/api/adexchangebuyer/v1.3 google.golang.org/api/adexchangebuyer/v1.4 I was thinking to make something like: dev-go/go-google-api-adexchangebuyer1.2 dev-go/go-google-api-adexchangebuyer1.3 dev-go/go-google-api-adexchangebuyer1.4 Then of course slotting seems valid so the version suffix can go away, if these are not compatible. > Only slot if the new version is not backward compatible. I agree on this slotting policy. It definitely is a bit hard to tell if they are backward compatible in an automated fashion. I think these may be compatible in many cases, however even though some things may remain the same between versions, the API endpoint changes with these numbers. It is hard to figure out compatibility and I think the general assumption by developers is none. >> Currently I'm re-wrapping https://github.com/odeke-em/drive (I had done >> this before when there were no Go helper eclasses). > > Oh, that could be handy for drive users. > It's a decent alternative to what was Grive. Although I have only learned recently of the fork to fix Grive for the newer APIs (already on Portage). The other option on building Drive is to emulate `go get` (put itself and all deps in SRC_URI and fix up a GOROOT to compile with). Some packages already do this partially, like go-oauth2 which grabs other things in SRC_URI that could be separated out. Go is nice, but is difficult to package. Andrew
