Outdated Linphone packets

[Simon Morlat]

Hi Bernhard,

Thank you very much for your detailed answer.
I realize I was wrong about the need for a tarball.

This was the case for linphone-desktop ("git tag" gives you all latests 
stable releases), but no longer for our dependencies, that were only 
referenced as git submodule of linphone-desktop).

So we are going to setup a consistent tag policy for all our components.

You 're right about the need to be careful with ABIs, and I know well 
what is the SO numbering policy. The next update will require to rebuild 
kopete as we are going to increase the SONAME abruptly, but after this 
one we will try to manage backward compatibility as best as we can to 
ease the life of our downstream users.
I'll get back to you as soon as we have something ready. We plan to make 
a 4.2 linphone-desktop release in september. Our objective will be that 
this release will also be debian ready.

Best regards,

Simon


Le 8/9/19 à 22:44, Bernhard Schmidt a écrit :
> Hi,
>
>>> - a linphone-sdk source tar.gz package containing all source code for
>>> libraries, with a cmake script that builds everything in one pass, but
>>> using debian included dependencies for our externals (soci, xerces,
>>> opus, libvpx, mbedtls...). Everything goes to a DESTDIR-like root-fs.
>>> - a linphone-desktop tar.gz package contaning the new QT5 graphical user
>>> interface, that depends on libraries built by linphone-sdk.
>>> Would this be helpful and sufficient for Debian developers to
>>> - create debian packages for all linphone subprojects (bctoolbox, belr,
>>> ortp, mediastreamer2, belle-sip, belcard, liblinphone)
>> Sounds okay, but please do not include checkouts of the foreign modules
>> into your tar.gz. Even if the actual compilation would be against the
>> system libraries, carrying those foreign projects in the source tarball
>> requires needless copyright examination. Or repacking, both is cumbersome.
> Forgot to add:
>
> Something that is also very important for Debian (and most other
> distributions) is proper maintenance of shared libraries. There can only
> be one version of each library in a release, so all reverse depencies
> need to be built against it. When there are foreign projects using these
> libraries, they need to be able to do it in a stable way. This means
>
> - Don't easily change the API, because it might break existing projects
> to build against the new version. This would be a blocker for inclusion
>
> Actually AFAIR this prevented having an updated linphone version in
> Stretch (Debian 9, released three years ago) because kopete did not
> build against the new version of mediastreamer, which blocked the update.
>
> - Don't break the library ABI. Don't drop or change exported symbols. If
> absolutely necessary bump the SONAME.
>
> See https://wiki.debian.org/UpstreamGuide for more information.
>
> This is less of a concern if only the linphone-ecosystem uses the
> libraries, but right now there is at least kopete using libmediastreamer
> and libortp. If this is something you are absolutely unwilling to
> support, please document this and get in touch with Kopete upstream to
> get this dropped.
>
> Bernhard


-- 
Simon Morlat, manager and co-founder
Belledonne-Communications SARL
http://www.belledonne-communications.com
Phone  +33 952636505