I am also pretty baffled by some projects' newfangled release / tag naming conventions, and how to make them fit the Debian packaging process.
In the case of azure-sdk-for-go, I see that upstream has tags in the form of "sdk/azcore/vX.Y.Z" (among many others). Can we assume that "azcore" is as close an analog as we are going to get to the former simple "vX.Y.Z" tags?
Several large libraries (e.g. aws-sdk-go-v2) seem to now publish releases almost daily, which simply isn't rational or feasible for Debian packagers to track. We need to identify which releases are actual major milestone releases, and not merely a dependency bump in go.mod due to some overly eager dependabot.
Obviously we will need to bump the epoch on such packages where the new upstream tagging convention would result in a lower version number than what is currently packaged.
On 20.12.23 04:19, Maytham Alsudany wrote:
Source: golang-github-azure-azure-sdk-for-go
Severity: important
X-Debbugs-Cc: debian...@lists.debian.org
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
OpenPGP_signature.asc
Description: OpenPGP digital signature
