[Clam-devel] Re: RFS: CLAM, C++ library for audio and music

[David García Garzón]

A Dimecres 25 Març 2009 06:09:25, Paul Wise va escriure:
> On Wed, Mar 25, 2009 at 12:25 AM, David García Garzón
>
> <dgarcia at iua.upf.edu> wrote:
> > * The only lintian warning i get is:
> > W: libclam13: package-name-doesnt-match-sonames libclam-audioio13
> > libclam- core13 libclam-processing13
> > As suggested by a debian developer and according to libpkg-guide we
> > joined the library as the three libraries are going to change the soname
> > at once on every release (i am also upstream release manager), but in
> > some sponsoring guidelines i read that sponsored packages should be
> > lintian clean including warnings. Should i ignore the warning or should i
> > split the binary packages?
>
> It seems silly to have libclam-audioio, libclam-core and
> libclam-processing when you change the SONAME on all three at the same
> time. Why not just have libclam?

That's a good point. That will silent lintian but we should change all the 
build system which now is splitted in three. If i can't ignore that warning i 
would prefer splitting the packages. Splitting the package will be a matter of 
reverting some changes we did. We splitted the library to provide modurarity 
and handling the build in three parts to speed up dependency checking and link 
time. Indeed libclam-processing is still too big for my taste. 

Another of the goals of the lib split was reducing programs third party 
dependencies by selecting modules, which would be ideal from a debian point of 
view if we separate packages, but the reorganization went half the way and 
current partition still doesn't make that feasible. Most applications will 
need an 'audioio' method (ladspa, jack, portaudio, portmidi, libsndfile, 
libmad...) and some 'processing' module and both depend on 'core'. We 
(upstream hat) plan to do a split them for a next release so that audioio 
factorizes out dependencies and processing gets into smaller components. Until 
then it is just a monolithic lib split in three parts. :-(

So, by discarding joining the libs, what are remaining the options? splitting 
packages? ignoring warnings?

> Changing the SONAME at every release isn't the right thing to do
> either, it should only be changed when you break the ABI.

CLAM has X.Y.Z version schema, and 'guarantees' no ABI change for X.Y. which 
is coupled to the soname. That said, i have to recognize that last releases 
have been X.Y.0 so ABI broke. Until now, such changes have not been a big 
issue since most of the users build their applications from sources and a nice 
porting guide and scripts were provided for each X.Y release. Your notice of 
warning at the IRC made me aware that as soon as we get packages depending on 
clam in debian we should avoid or retain ABI incompatible changes and make 
more X.Y.Z releases.

Thanks, again, for the feedback.
David.

http://clam-project.org/wiki/Version_Migration_Guide

-- 
David García Garzón
(Work) dgarcia at iua dot upf anotherdot es
http://www.iua.upf.edu/~dgarcia