On 21/08/15 08:46, Richard B. Kreckel wrote: > This patch replaces libginac5. This is in line with what the bug report > says: "Rename the library package, append "v5" to the name of the > package (e.g. libfoo2 -> libfoo2v5)". > > I can do that and will do so ASAP if it's the right thing to do.
The short version is, yes the rename is the right thing to do. Please check that all your library's library build-dependencies have started their transition, or do not need a transition. Looking at <https://packages.debian.org/source/unstable/ginac>, neither cln nor gmp seem to need a transition, so I think you're good to go. In case you maintain other affected packages: if build-dependencies have not yet started their transition but they need one, please help their maintainers to start the transition; if it is unclear whether they need a transition or not, please help to analyze that. When the versions of all your library's build-dependencies in unstable are appropriate, please start your library's transition in unstable too. Versioned build-dependencies, to make sure the renamed version of the dependency is picked up, seem like a good idea in this situation. > But > don't the two packages have to coexist? (After all, one of the concerns > is to not break packages which are not in the archive!) Programs compiled against ginac with g++-4.x got a shared library dependency on libginac.so.5, which they assume will the g++-4.x-compatible ABIs. The shlibs system turns that into a dpkg dependency on libginac5. Programs compiled against ginac with g++-5.x also get a shared library dependency on libginac.so.5, but *they* assume that will mean g++-5-compatible ABIs. There can only be one libginac.so.5 in the highest-priority location of the public library search path, and it cannot mean both things. The broken situation would be that you have programs (or libraries) foo and bar installed, both linked to libginac.so.5, with foo expecting the g++-4.x ABI and bar expecting the g++-5 ABI. Depending which version of libginac.so.5 you had installed, either foo or bar would crash. What we are doing by renaming the package is to force this situation not to exist: foo would depend on libginac5, bar would depend on libginac5v5, and dpkg will not let you have them both installed at the same time. This would break foo in the sense that it becomes uninstallable, but there's no way to avoid that. When the majority of the renames have been started, the release team will schedule several thousand binNMUs (rebuilds) to make everything installable again. The release team are not currently scheduling rebuilds where it is not strictly needed, because if they did that, many C++ packages would end up being binNMU'd multiple times by the time the transition completes; that's quite "expensive" on slower architectures like arm* and mips. S
