Jay Berkenbilt wrote:
The recent threads on sonames and package names convinced me beyond a doubt that I made a mistake in the names of the vips packages.
Oh dear...
[...] Right now, the vips7.10 source package creates four binary packages: libvips7.10, libvips7.10-dev, libvips7.10-tools, and libvips7.10-doc. My intention is to do the following:
Create new source package "vips" which will create four binary packages: libvips10, libvips-dev, libvips-tools, libvips-doc. (10 is the current soname.)
There's no real reason to change "libvips7.10" to "libvips10" -- the package name doesn't have to match the soname, it just has to change whenever the soname does. So if you've matched "libfoo" to a soname of 4, you don't have to do anything beyond renaming the package when version 5 comes out -- and that's the point you should say "ah, I can call it libfoo5 now".
Changing the -dev package name isn't a huge win -- having it Provides:/Conflicts: with "libvips-dev", encouraging your users to build-depend on the unversioned -dev, then just changing the package name when your soname next gets bumped is just as effective.
OTOH, when the soname gets bumped you generally don't want to change the source package name so you get to avoid waiting for bugs like #283145 to be dealt with, and source package names basically don't affect users at all.
libvips-tools and libvips-doc likewise can probably lose their version happily, presuming people who Depend: on libvips-dev today, and end up getting the tools from soname 11 aren't going to be unhappy. But for both of those you should be able to just have "libvips-* Conflicts:/Provides:/Replaces: libvips7.10-*" to satisfy dependencies.
Each package Conflicts with the package it replaces with a version << the future dummy transition version of the existing packages and Replaces the old package as well. For example:
I'm fairly sure the above should ensure you don't need any dummy packages, and gain all the benefits you were aiming for. Dummy packages are almost always evil.
Cheers, aj