Re: Another approach to golang-* version migration
Hi,
...
> 4) If some reverse dependency REALLY REALLY cannot move to v6, we need
> to add a new source package golang-github-foo-bar-v5 to the archive,
> to build the old binary package, typically golang-github-foo-bar-dev
> or golang-github-foo-bar-v5-dev. This can go directly to unstable,
> and the reverse dependency that is stuck can be updated to use that
> new package.
This would make sense to me, in particular now that the NEW queue
works and renaming packages is not something that takes up to a year
to do. I would prefer that golang-github-foo-bar-dev always points to
the latest version, and the old versions are available with the
numbers.
Currently I am looking at these 3:
https://tracker.debian.org/pkg/golang-github-urfave-cli (v1)
https://tracker.debian.org/pkg/golang-github-urfave-cli-v2
https://tracker.debian.org/pkg/golang-github-urfave-cli-v3
My plan is to review all packages that depend on
golang-github-urfave-cli-dev (v1) and switch them to depend on v2 or
v3 and with the goal or removing golang-github-urfave-cli and no
package depends on the very old v1.
Then I would rename golang-github-urfave-cli-v3 into
golang-github-urfave-cli but inside include a metapackage
golang-github-urfave-cli-v3-dev that reverse dependencies can continue
to depend on.
And going forward make sure all packages depend on
golang-github-urfave-cli-dev unless they really are incompatible with
and depend on v2, and in that case depend on
golang-github-urfave-cli-v2-dev that is kep around until its reverse
dependencies drop to zero.
> I really don't care, but I think we should have the strategies well
> documented, because this is tricky for us all. Maybe we can give up on
> recommending any particular strategy and just document all three
> distinct approaches that I'm aware of.
I agree we should have a unified way to do this, and there should be
enough discussions to have multiple people to understand pros and cons
of different ways of doing it and landing on the agreed upon best
practice.
For that the happen I hope to see more people participate in mailing
list discussions and also "cast a vote" by thumbs up/down the concrete
change proposals at
https://salsa.debian.org/go-team/go-team.pages.debian.net/-/merge_requests.
Reply to: