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
Attachment:
signature.asc
Description: PGP signature