Arch Linux User Repository

I did a split of the package to 3 packages: google-cloud-cli, google-cloud-cli-bq, google-cloud-cli-gsutil. There is also package containing the bundled python for those who want it or as a dependency to the gsutil (current version 5.24 does not work with python 3.13 out-of-the-box, although 5.25 which is already available on github should). I am also testing to include other "components".

If there will be interest, it's also possible to split the manpages to another package. So for those who don't want them, the install time can get faster and size significantly smaller.

I have tried not to break anyones installation, so please try to install the 3 mentioned packages and it should work the same as before.

You don't need bundled python for the gcloud to work, and I would advice to use gsutil only if yo really have to. The prefered way is to use gcloud storage anyway.

@troyengel ah, you mean:

https://dl.google.com/dl/cloudsdk/release/sha1.txt

and

https://dl.google.com/dl/cloudsdk/release/sha256.txt

Cool. Thanks! I should have noticed that in the prepare() step. It looks like the sha1.txt file was obsoleted as of v148.0.1 of the SDK.

If you have a moment, hit me up on IRC (freenode) as sudoforge or via email. I'm planning some big changes, namely:

• Slimming the google-cloud-sdk AUR package to only include alpha and beta components
• Adding AUR packages for each individual component

This will make the available AUR packages match Google's DEB and RPM releases. Most importantly, I think (once I complete the above refactoring) we should submit a request to merge this package into google-cloud-sdk. After that, I'd be happy to add you as a co-maintainer to it and whatever other packages you'd like to support. What are your thoughts on this?

@sudoforge I used to maintain the larger package you now do (google-cloud-sdk) for a few years (2015-07-18 to 2017-06-14 in git, no logs from AUR3 pre-git). I looked in the comments, on 2017-01-13 when I was preparing 139.0.0 I wrote 'Heya all, as I was preparing 139.0.0 for release just now I notice in the sha1.txt a number of new downloads appeared that has "for packagers" in the directory name' (back then it was sha1.txt).

So I'd have to say that between 138.0.0 and 139.0.0 I saw it first appear in the hash checksum file, not that I'd read about it on their docs or saw a blog post or anything like that... doesn't really help you with your goal, I know - sorry. But does give you a date when it seemed to first have happened, which might be a clue somehow to help. Here's the commit where I first "found" sha1.txt (I don't remember how) and implemented it in the PKGBUILD we both use today as sha256.txt: (edit: I can't get this comment to stop butchering the link, look in the Changes for 0.9.84 -> 0.9.85 dated 2015-11-06 )

Hope some of this helps! Good luck tracking those archives down...

@troyengel where did you find the "for packagers" archive? i'm trying to find archives for the different components in order to create packages for them, and i'm not able to find current archives for anything.

@sudoforge - thanks! Following your hint, I see various google hits and was able to locate a random package on Debian that shows it in use, so we can follow their pattern: https://www.apt-browse.org/browse/debian/jessie/main/amd64/xss-lock/0.3.0-1/ (edit: and confirm now the Arch package does the same - https://www.archlinux.org/packages/community/x86_64/xss-lock/ )

If y'all can work out the file changes needed, I can integrate here as a patch as well etc. Thanks for the heads up that just copying it won't work, will wait on a solution. @MaddyBoo has never returned to pick on this conversation...

@troyengel (RE: zsh completions):

The zsh package owns /usr/share/zsh/site-functions, which is a good location to put completion files. This is where the zsh-completions package puts its completion files, and is (from my experience) included in the default $FPATH.

It's true that there isn't a well defined convention for where completion files should live, but this seems like a pretty sane choice to me.

It should be noted, however, that the completion.zsh.inc file will not work in its current form. It cannot simply be copied to /usr/share/zsh/site-functions/_gcloud. Google intends for the user to source this file in their shell, and I suspect this has something to do with it.

I haven't spent time debugging this, but there will need to be modifications to the file in order for it to... well, work. I'm a co-maintainer of the google-cloud-sdk package, so it's on my list of things to check out, but isn't a high priority.

Thanks for the update!

Hi @oxplot I would also like to help maintaining this package. How can I help you?

@oxplot any chance this can be updated at some point in the near future? I'd be happy to co-maintain this and help with updates.

@troyengel I understand, and you should of course keep to your vision :) A minimal package is exactly what I want since I have to install additional components anyway. I'll keep using this and apply my "hack". Thanks!