Bug#892325: Outdated Linphone packets

[Wadel Julien]

Yes, one of the difference between 4.2 and 4.1 is that the code depends 
of the linphone-sdk, not of all submodules.
You can check that :
https://gitlab.linphone.org/BC/public/linphone-desktop/tree/4.1.1/submodules
https://gitlab.linphone.org/BC/public/linphone-desktop

In other words, from the point of view of Desktop 4.2, it needs versions 
from "4.4 SDK". It doesn't mean that all SDK submodules needs to be 4.4.
I'm precising 'from' because you can use earlier versions, old functions 
are just marked as deprecated if it can be. It will be the case for the 
Desktop 4.2, but starting with SDK 4.4. The Desktop 4.1 was based on 3.12!
So for your concerns, it is more about a SONAME issue. There is a bump 
between 4.3 and 4.4. We are checking all SDK submodules to update SONAME 
for the 4.4.

It's why I incite you to start from 4.4 and not from 4.3.

Binaries that we release will be on the last version of SDK, so it is ok 
to give the whole updated stack for this case. I gave you the links on 
Appimage in order to see something that works on Linux ;)


Bernhard Schmidt wrote:
> Hi Julien,
>
>> I'm not fully aware about the packaging process on Debian but Linphone
>> Desktop 4.2 will be based on 4.4 of SDK for sure.
>>
>> Even it is currently on development, the 4.4 is near to be released and
>> is enough stable to begin to work with. In addition, I think that you
>> will have to use all 4.4 libraries because there is no point to mix
>> versions. I can confirm you that the Doxygen issue is fixed on this
>> version.
> So if I get you correctly, the only supported way to build and run
> linphone-desktop 4.2.x will with all of
> bctoolbox/belle-sip/ortp/mediastreamer2/bzrtp/belr/belcard/liblinphone
> 4.4.x?
>
> When updating your libraries, will newer versions (i.e. 4.4) either be
> API/ABI compatible with the previous versions (i.e. 4.3) or have a
> SONAME bump? Sid/Testing is basically a rolling distribution, we need to
> be able to start upgrading for example belle-sip with the new upstream
> version without fatally breaking the not-yet-updated part.
>
> In other words, I have understood that building (for example) linphone
> 4.4 with belle-sip/mediastreamer 4.3 is not supported. Is building
> liblinphone 4.3 with belle-sip/mediastreamer 4.4 supported?
It will depends of SONAME but I don't think it is supported as there is 
a bump between these versions.
>
> Debian tries to have as relaxed dependencies as possible. If for example
> liblinphone would be built with belle-sip 4.4 present, but only use
> library symbols that are already present in belle-sip 4.3.1, the build
> system would express a dependency of "libbellesip0 (>= 4.3.1)". In
> general Debian would allow a partial upgrade, a runtime error would be a
> bug. So if that's the case we need to make sure all libraries migrate at
> once and have very tight relationships (both at build-time and for the
> binary packages).
>
> https://wiki.debian.org/UpstreamGuide has a lot of information.
>
>> By the way, an Appimage on the last version of the application is based
>> on 4.4.0-beta-13 and can be found here :
>> https://www.linphone.org/snapshots/AppImages/Linphone-4.2.0-alpha.63+59c4cc1.AppImage
> If your whole development model is catered around AppImage (or snaps)
> and basically only supports atomically replacing the whole stack and
> building it from a single repository I would rather not have linphone in
> Debian at all. After all we have to support it for several years after
> release.
>

> Bernhard