Shengjing Zhu <zhsj@debian.org> writes: > Thanks for raising this. We should have better guidelines on this. Would a general policy to always prefer "golang-import-path" as the source package, and produce "golang-import-path-dev" package when there is only one version in play, and have a multi-upstream tarball package named "golang-import-path" for the source and "golang-import-path-v3-dev" for OLD versions and "golang-import-path-dev" to always track latest upstream version (when that latest needed version is needed by some other package in debian) work? The migration path for a library with many reverse dependencies stuck on old versions would then be to introduce a new "golang-import-path-v3-dev", change all reverse dependencies stuck on that old version to use *-v3-dev instead of *-dev, and then let "golang-import-path-dev" track v4, v5 or whatever is latest. This requires a NEW roundtrip to add a new binary package name, which is a hassle, but I find the alternatives to be worse. > This is not a unique question for Go libraries. Other languages also > have. Just looking at these C libraries which have versions in the > -dev header library name. I don't think we have a documented rule for > the C language. Probably the common sense is to put the version in the > source/binary package name, when the transition to a new version is > hard. For C libraries, I think this has slowly (10+ years) been migrating towards having libfoo-dev and libfoo42 packages for shared libraries to allow smooth ABI migration strategy. But with Go the packages this split is not possible because everything is static. /Simon
Attachment:
signature.asc
Description: PGP signature