Otto Kekäläinen <otto@debian.org> writes:
> One more option came to my mind here: vendoring. You could put the v4
> into debian/vendor/github.com/.../v4
>
> In particular if:
> - the dependency is not properly defined, a local debian/vendor/*
> thing is easier to inject into the build
> - the dependency is very specific, e.g. v4.x.y
> - you don't want to go via NEW queue to introduce a -v4 package
> - only one or _very few_ packages depend on it and no new packages
> will ever depend on it
Indeed, and having already gone through the trouble of getting
'golang-github-cenkalti-backoff-v4' quickly past NEW and in the process
of getting the 10+ reverse dependencies to use *-v4-dev and migrate them
to testing, I'm somewhat inclined to believe that vendoring v4 in the
otherwise v5 *-dev package would have been simpler.
Still, several of the reverse dependencies would still had to be patched
because of the versioned /v4/ vs unversioned imports that seems to be in
wide use for this package.
So I'm somewhat happy that I learned to do a migration like this, but
also unsatisfied because I think this is a lot of time spent on things
that nobody should have to spend time on.
Once this golang-github-cenkalti-backoff-v4 transition is completed, I
think the end result will be nicer than any of the alternatives, though,
including the vendoring approach.
This process is feasible to do for a ~10 package migration, but I'm not
sure we should do it for 100+ packages, if there is ever a need for
that. At least not for a one-person assignment. Embedding two versions
of the same upstream into the same Debian source package is less work,
produce the same end result, but may violate some policies.
/Simon