Outdated Linphone packets

[Bernhard Schmidt]

Hi All,

I've been bored enough to update the whole linphone stack to 4.3.0 and I
got packages that compiled on top of each other (bctoolbox, belle-sip,
belcard, belr, bzrtp, ortp, mediastreamer2, linphone). These are not
cleaned up and ready for integration, some of them need a trip through
NEW, but overall it looks like it could work. Lack of bcunit in Debian
was a bit of a bummer, as I had to disable unit tests for almost every
package manually, otherwise it would try to link to some bctoolbox
tester headers that simply are not installed.

However, I've hit a major blocker with linphone-desktop. First of all,
there does not seem to be a release tagged for ages, with 4.1.1 still
being the last one in July 2017.

I've tried the release/4.2 branch and got hit by linphone-desktop
requiring a new external library, minizip. There is an old package
called minizip in the distribution

https://tracker.debian.org/pkg/minizip

which according to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843617 appears to be
an outdated fork of the contrib/minizip directory in src:zlib, which is
not installed at all.

https://gitlab.linphone.org/BC/public/external/minizip seems to be yet
another fork, I think upstream is at https://github.com/nmoinvaz/minizip .

I currently do not have the energy to package this, so right now we're
stuck. I can agree to push and polish the other packages, but I'm not
going to package minizip.

Looking at the bugreports I don't think we're doing our users a favour
in keeping linphone 3.12 with the old GTK+ frontend in Debian, and most
of it has already dropped from testing due to FTBFS with GCC-9 or the
dependency on Python2. So I'm considering dropping all of it from
testing and calling it a day.

Bernhard

Am 13.08.19 um 11:19 schrieb 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
> 
>