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.

@rdoursenaud - this seems workable, since I don't live this SDK code can you expand upon what "add the app-engine-python component" entails? is it similar to how we're bootstrapping the kubectl component? ( https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=google-cloud-sdk#n54 ) Adding the replaces/obsoletes and /usr/bin/ links is a no-brainer, just delete the lines in the PKGBUILD that are actually deleting them I put there because of our conflicts in the first place. :)

Hi @troyengel, maintainer of google-appengine-python-php here. Looking at https://cloud.google.com/appengine/docs/php/download and https://cloud.google.com/appengine/docs/python/download it seems that the Google Cloud SDK is now superseding the Google App Engine SDK. I thus plan on dropping the package. To ensure a smooth transition, your package must provide the appengine related tools. Could you please add a replaces=('google-appengine-python-php' 'google-appengine- python' 'google-appengine-php'), install '/usr/bin/dev_appserver.py' and '/usr/bin/endpointscfg.py and add the app-engine-python component? Or should we try another approach to provide component level packages, maybe?

I don't see any harm in this and it's trivial because we're already installing a profile.sh - there's very little google-fu hits when you look for GOOGLE_CLOUD_SDK_HOME so I think it's just something people started doing. I'll put in on my checklist for the next release (130.0.0).

It would be very helpful if this package set the GOOGLE_CLOUD_SDK_HOME environment variable or did something else to allow App Engine plugins to detect where the Cloud SDK home is. The Gradle plugin, for example, is unable to find the SDK on its own. Here is the mechanism plugins use to find the SDK: https://github.com/GoogleCloudPlatform/appengine-plugins-core/blob/75255413b2f92ebe841238241ff40014bc2be0e3/src/main/java/com/google/cloud/tools/appengine/cloudsdk/PathResolver.java#L35

I will add a conflict once I get back to my build machine -- what that other package is doing is their concern, I am *intentionally* adding kubectl during the build process to this SDK package to avoid having yet another package for no reason, this utility belongs with this SDK. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=google-cloud-sdk#n53 This package has been around a lot longer than the kubectl-bin, those packagers should be advised to also set a reverse conflict with google-cloud-sdk.

Hi, can you please add conflict with kubectl-bin package? Or even better instead of installing kubectl, just add this package as dependency. Otherwise you get this: error: failed to commit transaction (conflicting files) google-cloud-sdk: /usr/bin/kubectl exists in filesystem Errors occurred, no packages were upgraded.

The symlink has been removed (it's listed in the RELEASE_NOTES for 124.0.0 as a new addition) for /usr/bin/endpointscfg.py to prevent conflict, and python2-crcmod has been added as an optdep. Release 124.0.0-2 pushed.

Seems a new conflict is here: google-cloud-sdk: /usr/bin/endpointscfg.py exists in filesystem /usr/bin/endpointscfg.py is owned by google-appengine-python-php 1.9.40-1

You should list `python2-crcmod` as an optional dependency since `gsutil` will make use of it. You can see that at https://cloud.google.com/storage/docs/gsutil/addlhelp/CRC32CandInstallingcrcmod

They've fixed the bootstrapping error in 98.0.0 as promised, the code looks rather different now. I backed out our fix with this release of 98.0.0-1 package.