[Justin Pryzby] > If each runtime package Conflicts+Provides+Replaces the virual > package libgdal, then you will be able to ensure that only a single > such package is installed. And that is *far* from optimal. Few things are so annoying as wanting to install two packages which conflict for reasons beyond their immediate control (they happened to be built against conflicting versions of libgdal). The whole *point* in naming library packages based on their SONAMEs is to allow multiple versions to coexist on one system. Even if you only ship the latest one, a user who has an old libfoo1 on his system can continue to use binaries that rely on libfoo1 even when debian only ships libfoo2. [Steve Halasz] > Hopefully we can manage to split the two APIs into different > packages. But for now, how should I name the package when the ABI has > changed, but the SONAME hasn't? Splitting into two packages is indeed the best idea here. And I don't think it's particularly harder than what you have to do now anyway, each minor release (override the SONAME for the C++ library, rename the package, update the shlibs file). I'd go ahead and split the package now rather than later. If that really is untenable, your idea to put the whole minor release into the package name seems ok.
Attachment:
signature.asc
Description: Digital signature