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/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
