[email protected] writes: > For instance, I plan to start with golang-github-vultr-govultr (govultr). It > has two rdepends: prometheus and lego. Prometheus upstream still uses v2.*, > lego upstream uses v3.*.
Did you report upstream asking them to upgrade? This may save you a lot of time. > * Rename to *govultr-v2-dev, following the package renaming guide [3] > * Update lego and prometheus to point to v2 > * Create new package *govultr-v3-dev > * Bump lego to later upstream version and change dependency to v3 It would work, but there is ongoing discussion what the recommended approach for these migrations are. I think we should not forget trying to nudge upstream into moving to latest packages. Sometimes this happens quickly and effortless for active upstreams. > Also, should v2 be put in oldlibs as well as the unversioned package? Interesting idea! I think 'golang' is simpler though, I'm not sure we use any mechanism related to 'oldlibs' for Go packages. /Simon
signature.asc
Description: PGP signature
