sofia-sip packaging considerations

[Kilian Krause]

Kai,

> 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.

great! That's how we like to hear library upstreams speak. ;)


> 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. 

It's not about easier, it's about what makes sense. And using a
reference counter that is in sync with the SONAME and SOVER as package
name is just the most easy way of making sure things won't get screwed
up.


> 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.

Sure thing. In that case it'd just conflict and replace the old version
and apt would happily move to the new lib....-ua1-dev if done right.


> >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?

Yes, have the binary library have the SOVER included and the -dev
without the version reference of the actual API. That way the -dev only
points to the newest API it was installed along with. This of course
includes having the debian/control nail the depends to the exact same
version. What Mark meant was that binary rebuilds then only need to call
the source of a dependant application again into the buildd and "just
rebuild" without making any changes to its source. 


> >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.

Fine, that's what we got the separate package for. There we can bump
SOVER updates accordingly when required. 


[snip]
> -- 
> first.surname at nokia.com (Kai Vehmanen)

oups, unconfigured footer? Btw. the sig-delimiter is "-- " including the
whitespace after the two dashes. You may want to fix that as well while
at it. =)

-- 
Best regards,
 Kilian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/attachments/20060615/0dcb46b3/attachment.pgp