On 2026-10-21 03:31, [email protected] wrote:
This is an automated message from the Debian DFSG, Licensing & New
Packages Team.
The Debian NEW review of golang-github-ibm-go-sdk-core 5.25.1-1 has
been completed.
Decision: ACCEPTED
Reviewer: Andrew McMillan
Review comment:
Hi,
The LLM review about this not being made available on the /v5 seems
like it might be something worth looking into. If it's wrong about
this please reply so I can give it some feedback...
Thanks!
Full review details:
https://dfsg-new-queue.debian.org/reviews/golang-github-ibm-go-sdk-core
It's not "wrong", but the situation is ambiguous. We haven't had a
golang-github-ibm-go-sdk-core before, so this one provides /v5, and and
from one perspective that's that. No need to register the package name
with -v5.
We use version specific package names when there's ambiguity, or more
precisely when the multiple versions are actually packaged. More
commonly it happens when we start with the original release (implicitly
/v1), and then later upstream makes a /v2 release. So we need to make a
-v2 package to distinguish the two. And sometimes we still want to keep
using the /v1 API.
The case of golang-github-anacrolix-missinggo (/v1) is particularly
bizarre. golang-github-anacrolix-missinggo-v2-dev (v2) depends on
golang-github-anacrolix-missinggo (v1). That's bizarre enough, but it
just means missinggo-v2 is an extension of v1, it doesn't supersede it.
But that's not the truly bizarre thing, the truly bizarre thing is that
golang-github-anacrolix-missinggo (/v1) depends on
golang-github-anacrolix-missinggo-v2-dev (v2). Somehow it seems to work.
With golang-github-ibm-go-sdk-core we don't have any older (or newer)
version to conflict against. So the unversioned package works
(understood as /v5, as per the package version). We could rename it to
golang-github-ibm-go-sdk-core-v5 but nothing is conflicting if we don't.
Drew
