google-cloud-sdk: "gcloud beta sql connect" requires cloud_sql_proxy about pkgbuilds

[sudoforge]

opt-depend on e.g. cloud-sql-proxy-bin

Unfornately, this is a no from me. That particular package has been flagged as out of date for nearly a month with no update from the author.

and/or patch google-cloud-sdk to not require it from /opt/google-cloud-sdk/bin/cloud_sql_proxy, but use it via $PATH!?

This is fungible, but...

and have read what to do to manually install this component in https://aur.archlinux.org/packages/google-cloud-sdk#pinned-659642

Why does this not work for you?

[sudoforge]

Hey @blueyed, can you provide feedback to the above question?

[blueyed]

I've tried the approach mentioned at https://aur.archlinux.org/packages/google-cloud-sdk#pinned-659642 now.

However, it installed only version 1.18.0, while 1.22.0 would be available: https://github.com/GoogleCloudPlatform/cloudsql-proxy/releases

That appears due to the rapid's channel components list (outdated? / not updated?). However it appears to work.

My config (/opt/google-cloud-sdk/lib/googlecloudsdk/core/config.json):

{
  "config_suffix": "",
  "disable_updater": false,
  "disable_usage_reporting": true,
  "documentation_url": "https://cloud.google.com/sdk/",
  "release_channel": "rapid",
  "release_notes_url": "https://cloud.google.com/sdk/release_notes",
  "revision": 20210521145322,
  "snapshot_schema_version": 3,
  "snapshot_url": "https://dl.google.com/dl/cloudsdk/channels/rapid/components-2.json",
  "user_agent": "google-cloud-sdk",
  "version": "342.0.0"
}

[sudoforge]

Interesting find! I'm currently traveling for a wedding, but will look into this in detail next week.

Related: I've recently finished standardizing the build process and integrating this repository with my internal development workflow, which means that I can now focus on package adoption/creation -- namely, finally get around to packaging the external components. I don't have an active timeline for you, however, I'd expect this to be the first target and should be completed roughly around the end of next week.

[blueyed]

I've noticed that disable_updater gets reset (likely after a package upgrade).
It would be good if it could be persisted somehow, e.g. by merging updates from a file in /etc maybe?

[sudoforge]

@blueyed yes, updating the package would replace that file, however, I don't think patching it by default to enable management of plugins would be ideal, as users would become used to managing plugins in that way. I got sidelined with a few other tasks that required my attention, but I will be addressing the plugins in the future, which will alleviate any difficulty or repetition necessary for end users in regards to utilizing SDK plugins.