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 _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface