| 1 |
To correctly support the entire Google API library set, do we need a |
| 2 |
separate ebuild for every single one? This definitely can be automated. |
| 3 |
|
| 4 |
https://godoc.org/google.golang.org/api |
| 5 |
|
| 6 |
With golang-vcs, using google.golang.org/api for GO_PN is not working |
| 7 |
and I think it is because each package must be dealt with separately. |
| 8 |
|
| 9 |
Back story: |
| 10 |
|
| 11 |
I have an ebuild I made a while ago back when the norm was to hack up a |
| 12 |
copy of GOROOT minus the package and build the package with that root, |
| 13 |
then install. It is located here: |
| 14 |
|
| 15 |
https://github.com/Tatsh/tatsh-overlay/blob/master/dev-go/google-api-go-client/google-api-go-client-0_p20150428.ebuild |
| 16 |
|
| 17 |
I do need to update all my Go ebuilds for golang-* eclasses, not just |
| 18 |
this one, because the old way was to install to /usr/lib/go rather than |
| 19 |
/usr/lib/go-gentoo. |
| 20 |
|
| 21 |
But besides that, this ebuild was only intended to fulfil the |
| 22 |
dependencies of Odeke Drive (a Google Drive client, especially since |
| 23 |
Grive is now dead due to API changes). You can see this in the loop that |
| 24 |
only deals with the packages drive/v2 and googleapi. (Just to note, I |
| 25 |
would love to see Odeke Drive in the tree as there is no longer a |
| 26 |
working Google Drive client in the tree.) |
| 27 |
|
| 28 |
Thanks |
| 29 |
Andrew |
Archives