[Pkg-running-devel] Bug#789875: Bug#789875: needs to be removed

[Robert Helling]

Hi,

> On 12.08.2015, at 14:20, Christian PERRIER <bubulle at debian.org> wrote:
> 
> Agreed. Stop dealing with that upstream ("I believe that the
> design of most Linux distros is fundamentally broken" : how arrogant
> is that) and let's throw subsurface away as it is....or just fork it
> to make it distro-friendly.


there is a lot of anger that has accumulated over a long time in these statements.

Maybe it’s worthwhile to spell this out more explicitly since not everybody understands their basis and just sees the arrogance:

Subsurface decided to use a number of libraries including libdivecomputer (to be able to talk to a large number of dive computers), libgit2 (to be able to store its user data in git repositories) and libmarble (to show maps of dive sites).

By now, for all three we cannot easily rely on versions that come with distributions, for various reasons: libgit2 keeps changing its API at random times, even linking against a given version number does not ensure you find the API you expect. This means, a program basically has to know the commit of that library that it is linked against to be able to reliably talk to it. Plus, major distributions still provided very old versions of this library that were simply too buggy or missing essential features to be useful.

libmarble is a huge beast that keeps throwing bogus error messages when used from other programs than the main marble program. Plus they are not really too responsive when it comes to merge upstream patches for errors. So we decided to fork a lightweight version of it.

Libdivecomputer is also not too fast when it comes to merging patches which would imply that we would seriously limit the number of compatible dive computers that subsurface can talk to if we relied on the packaged version.

Therefore, to be able to provide our users with the best experience, we decided to compile our own versions of these libraries (some of them forks).

Being allowed to to that in a distribution (e.g. by allowing to link these statically) would make packaging subsurface much easier. Of course, in a distribution you don’t want all programs to statically link all libraries since that would defeat the purpose of having libraries, but if the versioning is so fragile, we don’t see an alternative. In particular when it comes to libraries where subsurface is likely the only program that uses them (check for yourself, which packages require these libraries in Debian?

Best
Robert

--
.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO
Robert C. Helling     Elite Master Course Theoretical and Mathematical Physics
                      Scientific Coordinator
                      Ludwig Maximilians Universitaet Muenchen, Dept. Physik
                      Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339
                      http://www.atdotde.de

Enhance your privacy, use cryptography! My PGP keys have fingerprints
A9D1 A01D 13A5 31FA 6515  BB44 0820 367C 36BC 0C1D    and
DCED 37B6 251C 7861 270D  5613 95C7 9D32 9A8D 9B8F





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-running-devel/attachments/20150812/8f533b9c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.alioth.debian.org/pipermail/pkg-running-devel/attachments/20150812/8f533b9c/attachment-0001.sig>