the package is big and has many functions implemented, but only a few are exported. Since newer packages require this package to provide all the functions, it would be usefull to have this package correct. If I'm correct, there was a problem with urpmi which has problems with a large list - but anyway, we have to find a solution for it. Atm I can't provide the restic update.
The problems comes from usage of fixed-size buffer in perl-URPM, truncating list of virtual packages: https://gitweb.mageia.org/software/rpm/perl-URPM/commit/?id=950d56e991d307b9b60bde8f51920bee3d1bc61c And here is the related discussion on the mailing list: https://ml.mageia.org/l/arc/dev/2022-12/msg00241.html
I remember that discussion. I'm not following the development of urpm. Is this fixed? Or is our plan, to add another provides to azure each time a package needs it? Or can we just split up the azure package into subpackages?
In order to update restic (to adress CVE-2022-41723), I need a few more subpackes from azure. Can you please provide: github.com/Azure/azure-sdk-for-go/sdk/azcore/streaming github.com/Azure/azure-sdk-for-go/sdk/storage/azblob github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/bloberror github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/blockblob github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/container It looks like go makes VERY much use of modules and package managers. Every update of a package has new requirements. I'm not sure how we are going to handle this in future...
and every build needs different versions...
Those components are not present in current package version, an update to a new version is needed first. And this update requires quite a lot of additional packages not present in the distribution...
Those dependencies are actually shipped by golang-github-azure-storage-blob-devel. I still don't understand why they are not advertised through dependencies, through.
I've asked the question about packaging go-packages on dev list. Stig suggested, to pack all dependend subpackages as a vendor.gz and add it to the package itself. Just adding and managing a whole bunch of go-subpackages does not help much. And fixing security issues requires to rebuild all packages using it. IÄm not sure what the best sulotion is, but either has its drawbacks.