Re. subsurface: FTBFS in experimental

[Lutz Vieweg]

This thread has turned into a bitter fight over "distribution policies"
vs. "upstream maintainer's freedom of choice", where I see valid arguments
from both sides as well "too much emotion".

To contribute another view point:

I am using the most recent and up-to-date CentOS release, also on the
laptop that I have with me to transfer dive data to, on boats on remote oceans.

Building Subsurface on CentOS from the sources has been very easy for
versions up to 3.x.

Building Subsurface on CentOS has been somewhat cumbersome starting
from version 4.0, due to lots of dependencies unavailable from the
distribution, but was still done in an hour or so.

Yesterday I endeavored to build the Subsurface git master head on CentOS,
and it was kind of a nightmare - everything, from just-one-patchlevel-version-of-
cmake-ahead-of-what-CentOS-delivers, continuing with of course Qt 5 in a
very certain version, and with lots of compile-time options to be tweaked,
up the customized libgit/gmerlin/marble libraries had to be built from
scratch, it took me ~50 attempts of error-spilling compiles until
all the strange dependencies were finally resolved, resulting in a
~500MB sized installation directory.

After compiling, I wondered whether I should be happy about this success.
Truth is, all the additions to Subsurface of the last 12 months or so
are all about features I don't need/want/desire - like marble -
or about things which I would rather like to have compile-time disabled - like
the "cloud" and "social media" features/threats.


But my frustration about the feature-creep induced inflation of the
number of dependencies does _not_ cause me to share the "distribution policy
should rule" standpoint.

In fact I am absolutely sharing the position that an application maintainer
shall be responsible for choosing what libraries to use in what version.
I would even welcome an option to statically link the binary when compiling.
The 500MB sized installation directory doesn't bother me, that's 0.013 €
worth of storage. And for one bug solved by a distribution shipping a newer
shared library, another bug is triggered by that library becoming incompatible
with some of the executables linked to it.
Regarding security: Subsurface is a software that does not require
privilege escalation, and it should not require InterNet access or data input
from untrusted sources at all, and in such use, bugs in Subsurface do not
threaten the users security.

Yes, it's wise to use 3rd-party libraries only when their API is reasonably
stable, and I would recommend to consider carefully not using a 3rd-party library
if that is not a given, especially if it's only about non-vital functionality.

So my bottom line is: Applications like Subsurface should retain control of
what libraries they use, but they should also allow for optional compilation
without non-vital dependencies, just like many projects (ffmpeg etc.) do.

Regards,

Lutz Vieweg