Packaging reSIProcate (unstable API / sonames / contrib directory)
Dear Mentors,
Neil, I CC you because you considered sponsoring the package.
I am packaging reSIProcate [1] a C++ SIP stack with some goodies.
My current packaging state is available via VCS [2] and as a preliminary
package at mentors [3].
Currently I've three major problems:
A) The API of the library is not stable. From version to version (e.g.
1.4 to 1.5) virtual functions, arguments, etc. are changing.
I've followed the libboost packaging and think it's also applicable to
resiprocate. So I'll have two source packages: resiprocate1.5 and
resiprocate-defaults.
resiprocate1.5 produces libresiprocate1.5 and libresiprocate1.5-dev
resiprocate-defaults produces libresiprocate and libresiprocate-dev
which depends on their versioned couterparts from resiprocate1.5.
So resiprocate-defaults eases library transitions and allows multiple
versions of resiprocate in the archive e.g. 1.5 and 1.6.
The newer versioned packages would conflict with all older ones. As
reSIProcate is released once a year at most, I don't consider this a
problem.
What gives me headaches are the daemons in reSIProcate. At the moment I
don't think they're ready for prime time (so they aren't packaged). But
this may change soon.
Is it OK for a daemon to be called repro1.5 and should a metapackage
exist? What about the config files?
B) ReSIProate libraries have no soname
First I've created a patch (features/soname-for-libs) which writes an
unversioned soname (file libresip.so has soname libresip.so). But this
way dh_shlibdeps don't write ldconfig calls to postinst. Also lintian
complains loudly.
So I've created another patch which writes versioned sonames and use the
three-numbered name system (file libresip.so.1.5.0 has soname
libresip.so.1.5). This is working fine and dependencies of library
dependent packages are correctly generated.
I'll send these two patches upstream.
Is it OK to change the file- and soname for Debian? The only
disadvantage I could think of, is an incompatibility to closed source
programs. But reSIProcate has so many configuration options, that
compatibility is unlikely per se.
C) The contrib directory and the copyright file
reSIProcate contains a contrib directory which contains several third
party libraries. I use none of them and also don't intent to do so.
Can I keep them in the tarball?
Must I list their copyrights in the debian/copyrights file?
Comments are highly appreciated!
Thanks,
Gregor
[1] http://www.resiprocate.org/
[2] http://git.debian.org/?p=collab-maint/resiprocate1.5.git;a=summary
[3] http://mentors.debian.net/debian/pool/main/r/resiprocate1.5/
Reply to: