While renaming packages there are a couple of things you should take care of before uploading:
- Make sure the package has to be renamed:
If there's a backward-incompatible ABI change (binary incompatibility) which prevents old programs from working with the new library: you need to change the library soname, and you need to change the library package name, but you usually should not change the -dev package name.
If upstream has made a backward-incompatible ABI change without a soname change, you need to make either a Debian-local soname change, or a renamed package which Conflicts: with the old package. This is a bad situation with no perfect solution; consider contacting debian-release for advice on your case if this happens to you.
If there's a backward-compatible ABI change, you just need to generate proper versioned dependencies, which shlibdeps should do for shared libraries (package renaming is not necessary).
If there's a backward-incompatible API change (source incompatibility) which prevents old programs from compiling with the new library: you will probably have to change the -dev package name. (Or add versioned Build-Conflicts with all packages Build-Depending on your old library, which is only appropriate if your library has a very small number of users.)
If there's a backward-compatible API change, you just need to make sure that users of the new features use proper versioned dependencies (-dev package renaming is not necessary).
- Usually any API change means a backward-incompatible ABI change (but not always -- careful upstreams can maintain ABI compatibility even with backward-incompatible API changes).
- The same principles apply to things other than libraries (interpreters supporting different language versions, etc.)
- Remember to add Conflicts: if two packages cannot be safely installed at the same time, but not otherwise.
- Warn all people involved:
- at least every maintainer of a package depending or build-depending on the renamed package
Check for bogus dependencies, and try to get maintainers to eliminate those before the transition. See SteveLangasek's email on the matter. The most extreme case is FreetypeTransition, where the majority of dependencies are bogus. Christian Aichinger has written a tool called checklib to search for bogus dependencies automatically (see also his announcement email).
- in many cases the best way to reach the maintainers (or step-in maintainers) is filing bugs (take care to not file duplicate bugs)
- note the rules about mass filing bugs
- it might be a good idea to have a usertag or use the blocking mechanism to keep track of the transition
- Contact the Release Team in case of a large (more than 10 packages involved?) transition, or if you have any doubt about the correctness or about the impact of the transition.
they might use OngoingTransitions to keep track about the status of the transition
Feel free to correct things or add content...