Outdated Linphone packets

[Bernhard Schmidt]

Dear Simon,

thanks for reaching out.

> I'm following up on the topic of Linphone debian packages.
> To introduce myself, I'm the original author of Linphone (started 18
> years ago...) and now co-leading the company centralizing the
> development around Linphone. I was in touch a long time ago with former
> Debian VoIP maintainers, but sadly this was lost as my activities were
> spread among too many aspects and platforms...
> 
> However I 'll be more than happy to see up to date packages of Linphone
> desktop app in Debian, and more than happy to help on this matter.
> 
> You are true when you say that we stopped releasing tarball packages,
> though I can assure you that development is still very active. The lack
> of tarball has been mainly the consequence of switching from
> automake/autoconf to cmake. Automake has recursive "make dist" that
> helps a lot in doing this task, but things are a bit more complicated
> with cmake.

Hrm, I'm not too deep into cmake, but I'm not sure what's done by
autoconf/automake that cannot be done with cmake. There are a lot of
projects doing releases that are based on cmake.

> As a result, we invite our users to checkout our git repos and use the
> tags and branches that indicate official releases. But I understand this
> not the way Debian works.

I don't mind using git tags, but I don't see any that are more recent
than 2017. Tagging a commit would be the equivalent for a release for
me, even if you don't release it as tarball.

I wouldn't even mind to use a specific git commit directly from master.
But I need to know what commit to pull, without reading all the
commitlogs or testing a specific version. So an always-in-development
master branch where I randomly select a specific date to pull all the
subproject repos is not workable for me.

If there is a time where you concentrate on stabilizing master, fine by
me. But then I don't see much difference to doing an official release
with a version tag and a generated tarball.

I'm not sure you fully understand the way Debian releases (or most
non-rolling distributions) work, so I'll try to explain. We, the
maintainers, at some point take an upstream version and package it. We
upload it into unstable, where it automatically migrates into testing
(which is roughly the next stable) unless it blows up badly. It gets
some testing by people living on the edge enough to run testing, but by
far most users run the old stable version that never gets updated to a
stable release.

About six months before the release we enter the freeze, where it
gradually becomes harder to impossible to update the upstream version.
So we're stuck at whatever version was selected at that time. As we get
closer to the release more people will start testing that version, but
still only a small part of the full userbase. When bugs are found we
cannot update to latest git HEAD, instead we need to find the specific
commit that fixed this issue and backport it.

When Debian is released, it needs to be supported for about three years
at least, again only with targeted bugfixes/backports, not by updating
to a new upstream version.

What we cannot use in this whole setup is to select some random upstream
commit, then getting a "why did you use THAT commit in the middle of a
big code refactoring, update to git HEAD you fool" when bugs occur deep
in the freeze or during stable maintenance.

> Recently, as the number of dependencies required for linphone growed a
> lot, we created a new meta-project called "linphone-sdk", which assemble
> with git submodules all our dependencies: bctoolbox, ortp,
> mediastreamer2, belr, belcard, but also some external dependencies:
> soci, xerces, opus, libvpx, mbedtls...)
> 
> This helps in doing standalone builds for iOS, Android, or other
> hardware devices with cross compilation. It also simplifies developer's
> life by avoiding to checkout multiple source code repository and
> iteratively build them manually. That's where we are now.
> 
> Based on that, we'd like also to provide something useful and simple to
> use for Debian maintainers, so here's my proposal:
> 
> We upload on our website:
> 
> - 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.

> - create a debian package for the linphone-desktop QT application ?

Probably, yeah.

> From a versionning standpoint and in order to keep things simple, all
> version numbers of linphone subprojects included in linphone-sdk would
> be aligned to be the same as the linphone-sdk tarball (similarly to what
> kde does with its components).
> The linphone-desktop and linphone-sdk package would independant version
> numbers.

Sounds good. Please make sure the version of the linphone-sdk is larger
than the highest version currently used in the subprojects.

Bernhard