[Clam-devel] Re: RFS: CLAM, C++ library for audio and music
David García Garzón
dgarcia at iua.upf.edu
Wed Mar 25 12:41:06 PDT 2009
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 García Garzón
(Work) dgarcia at iua dot upf anotherdot es
More information about the clam-devel