sofia-sip packaging considerations

[Kai Vehmanen]

Hi all, resending this from a subscribed address...

-- 
  links, my public keys, etc at http://eca.cx/kv

---------- Forwarded message ----------
Date: Thu, 15 Jun 2006 22:43:12 +0300
From: Kai.Vehmanen at nokia.com
To: msp at debian.org, pkg-voip-maintainers at lists.alioth.debian.org
Subject: RE: sofia-sip packaging considerations

Hello Mark and others,

btw, we are very close to releasing sofia-sip-1.12.0 which is a major
milestone to us, so timing for this debianization is good. :)

On 15 June 2006, Mark Purcell wrote:
>You might also want to run with a sofia-sip-doc package as a
>fair amount of documentation can be generated via doxygen.

Yes, this might be a good idea (we have a separate docs package in
our example RPM spec-files, plus switch to disable doxygen docs
altogether form created rpms ... as they do they quite a lot of
space).

>> 	1) -bin package - I have a binary package sofia-sip which
content
>> binary executable suitable for development and test
>Yes, I think -bin is fine..

Our RPM spec-file creates "sofia-sip-utils". The main "sofia-sip"
contains the library (yep, very different from Debian).

>> 	2) lib* and *-dev packages - having a look at libpkg-guide [1]
to
>> consult of how to name these packages according to the SONAME I

Now today/tomorrow we are going to release sofia-sip-1.12.0 which
is significant because it freezes the libsofia-sip-ua interface
v0 (.so.0). The glib bindings (libsofia-sip-ua-glib) won't be frozen
yet, but these are not widely used yet.

Our goal is to maintain long term API/ABI stability. So if all goes
well, we never need to update the soname of libsofia-sip-ua. But in
case something urgent comes up, we'll move to 1.14.0 and update the
soname accordinly. Otherwise, we'll move from 1.12 to 2.0 and continue
with the '...so.0' soname.

So from this POV:
>> grabbed the scripts listed there...  Running that over the shared
>> object libsofia-sip-ua.so.0.0.0, suggested package names are:
>> libsofia-sip-ua0
>> libsofia-sip-ua0-dev
[...]
>W: libsofia-sip-ua: package-name-doesnt-match-sonames libsofia-sip-ua0

Fine to us, as well as is omitting the zero. So whatever is easier
for you. One things with 'libsofia-sip-ua0-dev' that if
'libsofia-sip-ua1-dev'
is needed ever, the installed files will clash with files from
'..ua0-dev' (*.pc, *.la, *.so, ..). But I guess this can be handled
with package metadata.

>Personally my preference is -dev with the soname, that way, it
>is only a binary rebuild for soname changes of dependant
>packages.  Otherwise you need to change the dependant package
>everytime the soname changes on the -dev package, not just rebuild.

I'm not sure I'm quite following. So 'libfoo-dev' would
be better, as apps depending on it would only need a rebuild
if soname changes for 'libfooXX', right?

>Good..  Looks like upstream are running well with soname
>stability which is good.

Yes, this is something that is high on our priority list.
But do note that our glib bindings (built from the same source
package) are not yet quite as mature as the main lib, so we will
be updating the soname more frequently for this library. But we aim
to do most (hopefully all) the changes before the glib bindings start
to be used by more apps.

>The other issue which worth considering is the licencing
>issue, the documented copyright of the files in
>sofia-sip-1.11.9/COPYRIGHTS could be a cause for pain.  I
>would suggest you append the contents of that to debian/copyright.

Ok to me.

>Also I wonder if we need some sort of upstream OpenSSL
>exception, such as
>http://en.wikipedia.org/wiki/OpenSSL_exception as sofia-sip
>links with SSL?

Yes, we can take a closer look at this if needed. Hmm, we are
using LGPL, not GPL, does this problem apply to us?

These references seem to indicate that LGPL+openssl would be ok:
http://lists.debian.org/debian-legal/2002/04/msg00024.html
http://lists.debian.org/debian-wnpp/2002/07/msg00154.html

But let me know if there is something we should do.

-- 
first.surname at nokia.com (Kai Vehmanen)
Networking Technologies Laboratory, Nokia Research Center