On Tue, Sep 24, 2024 at 1:59 AM Daniel Swarbrick <dswarbr...@debian.org> wrote: > > 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. > > 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. >
Probably limiting the parallelism can help... > 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/azcore v1.11.1 > github.com/Azure/azure-sdk-for-go/sdk/azidentity v1.5.2 > > 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 > github.com/Azure/azure-sdk-for-go/sdk/internal v1.6.0 // indirect > > 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. > The reason that I propose to use 0.0~gitYYYYMMDD is to just track the latest commit in the mono repo. It just stops caring how the sub modules are tagged and avoid confusing in the single packaging version This is what I have done for golang-github-moby-sys-dev package which has similar mono repo that contains many sub modules. > I really hope we can make a decision and start to move forward on this. -- Shengjing Zhu
