Re: Bug#1059083: RFS: updated golang-github-azure-azure-sdk-for-go

[Daniel Swarbrick]

On 21.06.24 23:15, Shengjing Zhu wrote:

I think people are hesitant to sponsor because of the reconstruction
of the upstream repository.

<snip>

So I propose to create a new package called
golang-github-azure-azure-sdk-for-go-sdk, which contains all the
modules in the /sdk directory. And the package version uses
0.0~gitYYYYMMDD schema. This package doesn't conflict with the
previous legacy version, and can be co-installed.

  github.com/Azure/azure-sdk-for-go/sdk/azcore v1.11.1
  github.com/Azure/azure-sdk-for-go/sdk/azidentity v1.5.2




  github.com/Azure/azure-sdk-for-go/sdk/internal v1.6.0 // indirect







I really hope we can make a decision and start to move forward on this.

This is starting to get more urgent as we inch closer to the first trixie freeze. Today I tried building the currently packaged golang-github-azure-azure-sdk-for-go 68.0.0-2, with the intention of doing some ratt tests. I was shocked when it oom-killed my terminal (and thus sbuild) after eating 32 GB RAM plus 10 GB swap. Why does this package require such an absurd amount of memory to build? I can add some more swap, but I'm not sure how much more this thing is going to gobble up. As already mentioned by Maytham, Prometheus is just one package that urgently needs a newer version of azure-sdk-for-go. Debian currently has Prometheus v2.45.6, which is (was?) an LTS release, but since it has been superseded by a newer LTS v2.53.x, it's unlikely to get further updates. Without wanting to hijack the topic too much, Prometheus 2.53 would require these Azure packages: github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/compute/armcompute/v5 v5.7.0 github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/network/armnetwork/v4 v4.3.0 I expect that there are other applications which require other modules from the github.com/Azure/azure-sdk-for-go repo too. How do we go about packaging these? If we package each module as a separate Debian source package, that means we need to essentially clone the upstream repo n number of times in Salsa, each containing an almost-identical debian/control, just to produce a plethora of split packages - and believe me, there are a LOT of modules in the upstream repo. Or do we produce a single package that tracks the upstream "sdk/azcore" tags (and its associated version number scheme), but also include all the other sub-modules in that package? Maytham pointed out in another email thread that these other modules get interim updates independently of the "sdk/azcore" releases, and this might mean that packages which depend on such updates are stuck. However, given how rarely the existing golang-github-azure-azure-sdk-for-go package was updated, is the situation really going to be that different? We /could/ always release a "1.23.4-1+git20240923.coffeee" package to cater for these interim updates.

OpenPGP_signature.asc
Description: OpenPGP digital signature