[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: library naming problem

[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

Reply to: