Bug#1059083: golang-github-azure-azure-sdk-for-go: package outdated, upstream now versions components independently
Source: golang-github-azure-azure-sdk-for-go
Severity: important
X-Debbugs-Cc: debian-go@lists.debian.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi Go team,
The golang-github-azure-azure-sdk-for-go package is outdated, as
upstream have stopped versioning the SDK as a whole (last version was
68.0.0, 11 months ago), but are now independently versioning components
of the SDK (subdirectories of sdk/). e.g. sdk/to/v0.1.5 and
sdk/storage/azfile/v1.1.1
There are several questions to answer in order to determine how this
problem is dealt with:
- Should it all be kept into one source package?
- Should versioning in d/changelog follow HEAD?
e.g. 68.0.0+git20231220.f497335-1
- How should imports in the source code be dealt with?
Imports references the versions in upstream's tags
(sdk/storage/azfile/v1.1.1), which means either a find+replace of
all versioned imports, or a lot of symlinking.
- One binary package, that contains all the components?
- Or separate binary packages per component?
e.g. golang-github-azure-azure-sdk-for-go-sdk-to-dev
- Should we only package what is currently needed?
e.g. if sdk/storage/azblob isn't used in any packages, should
we bother to package it?
- Or should each component be split into their own source package?
e.g. golang-github-azure-azure-sdk-for-go-sdk-storage-azfile
- How will new versions be imported? (What will be put into
d/watch?)
- Maybe write our own sh script that does a sparse checkout of the
subdir needed and generates an orig tarball?
(New uscan feature perhaps?)
- Should we only package what is currently needed? i.e. should
anything without rdeps be packaged at all?
What are your thoughts on this?
Kind regards,
Maytham
-----BEGIN PGP SIGNATURE-----
iQJMBAEBCgA2FiEESl/RzRFQh8wD3DXB1ZeJcgbF8H8FAmWCXVMYHG1heXRoYTh0
aGVkZXZAZ21haWwuY29tAAoJENWXiXIGxfB/KhwQAJRHyDiuxgLlONkicejeRDiX
0ymLrjrRU6Pjc8m3BVK76a4msBS9bTex35dn0uOTFxeauAa5zYemWy3DF7BEIdQ7
IJu2hb/aTbPLqUjp4JhzvO46ureFeQYz2CPvZPNcaJYOCZSxFhDcwBYx6sx/98+r
rtKPXhz16GfWVwQ4AeuXfUfzpDwo79SXRCsqZTxbW2Zf+tUC7AS9/zUC/pcZgLub
GGQ5G5HoflN3BLlfNP2fYjeREiN179xEnqCzl+huPZZ9uRNVGlek5ZyH+Z0LHWBu
Ntn7tzob8S5NTbJt8ctk4X7UVJu1Uug5re7slRHnpRkofJ6talTCM+rlGylHMpNx
gjv5PLN9/1F8v2lsrq1woj+drQC99AAcmlFpOgfcMYXxxi5LvuzgDj0QGHgLhOCM
c/RMJksqlMKnY39HwJzBOxW0yn0CzOCiITMkCpK7ngde5BZGxbDL5UcCHR2KER7/
zV/R65AnEU1XMv5jg2KsejyJEYUykx0PD0HXxdZL0yazIO4yyPe7AysjzOeJdkZc
AvSHZdvuTpq6Wruo/RFskaDjV+Z2OGCmsFj8tEMi4ngq/kbrqRMlGI3DnDxYiqZs
2xvYblYBQdPz4JB7CIkHgntz1u5RB5lduKJNcI8aTSO2ScLq2k52k0FVElZMnY16
AEJfIWT7vOBIThOPIZXc
=xw0E
-----END PGP SIGNATURE-----
Reply to: