[Pkg-running-devel] Bug#789875: subsurface: FTBFS in experimental

[Christoph Anton Mitterer]

On Tue, 2015-08-25 at 17:55 -0700, Dirk Hohndel wrote:
> Being called stupid and arrogant is usually not a great conversation
> opener, but hey, I've been called worse.
Well I should have probably immediately apologised along the way, just
for the sake of politeness...

But the believe to know it much better than everyone else apparently
does qualifies quite well for arrogance.
And intentionally trying/wishing to keep the distros, while these are
at the same time the major and preferred way of software distribution
for the whole community where oneself comes from... for sure you know
the German saying "an dem Ast sägen auf dem man sitzt"... so I guess
that qualifies quite well for not making the smartest decisions.


> And because of those decades of proven philisophy Linux has taken 
> over the
> desktop, correct? And become the #1 targeted platform of all major 
> desktop
> applications.

Well the reason for this is for sure not that we have proper package
management systems and repositories... something which especially the
Windows world never really managed to do and which causes them quite
some problems - while everything which has them (or the
proprietary/evil versions of them, aka appstores) is quite successful
with them.

And apart from that,... if one wants to be like Windows or like Mac,
than the best is probably just to use these, ain't it?
I guess many people in the FLOSS world are actually quite happy with
Linux not having the 99% market share.
As the past has sown over and over again (even within FLOSS, take GNOME
as an exmaple): software with a too high market share tend to get evil,
broken or are simply targeted towards end-end-end-users and no longer
professionally usable.


> Sorry, that was snarky and I had promised myself not to be snarky but 
> to
> be constructive. So let's strike that last comment.
Yeah,... let's not go into completely unrelated topics...


> No, we have binaries available for Ubuntu, Fedora, OpenSUSE, Mint, 
> and, of
> course, Debian.
Then your download page is probably out of date, which still claims:
>Linux
>The Subsurface team is starting to make our own dedicated binaries
>available for a number of Linux versions.

It apparently misses Fedora and Mint, and Debian seems to be simply the
*buntu package?


Anyway,... I probably can't speak for all possible users but I'm quite
sure I'm not alone in not using such binaries by principle.
That's why distros exist, that people don't have to
maintain/upgrade/etc. all software themselves.
Not to talk about the security nightmares that your model of software
distribution brings along.


> So looking at my stats 4x as many Debian users are using the binaries 
> we
> provide than the binaries that used to come with the distribution. 
> But as
> a matter of fact both of those combined are less than 1% of our user 
> base.
And how do you get your stats? Making stats which are actually
representative and don't just show what one wants to see isn't that
easy.
popcon is probably no guarantee, as it's not installed per default.

End even if representative statistics would show that the upstream
binaries are used more than the distro ones, than the reason may just
be the artificial ones you've created yourself, by making subsurface
difficult to package and thus outdated in distros.


> And of course for the vast majority of our libraries we use the 
> system
> installed ones so the users do indeed benefit from any security 
> updates
> that will happen in the distribution.
Security isn't just in terms of up-to-date 3rd party libraries.
subsurface itself may have vulnerabilities and it wouldn't be the first
project whose website gets hacked and has forged binaries distributed.


> An application should be able to bring its own libraries for those
> libraries that it is so tightly coupled with that it makes no sense 
> to
> allow random combinations. So today Subsurface prefers to run against 
> our
> own branch of libdivecoputer and our own branch of libmarblewidget 
> and
> requires the very VERY latest libgit2 (0.23) and libgrantlee (5.0.0).
I think you're surely not the only program which has tightly coupled
3rd party libraries - yet other projects apoarently manage to properly
deal with that...
Either they find a way to better cooperate with the 3rd party libs
respective upstreams and get their needs into that code (as it could
perhaps be done with libdivecomputer),... or they take over / fork an
anyway slowly maintained project (again, libdivecomputer?),... or they
simply use other libraries which better serve there needs (Robert
complained about libmarble beeing buggy[0] - why not just using
something much simpler? marble seems to be anyway overkill for
something like subsurface).

And even *if* you say that a fork is really needed for certain libs,
why not doing it properly?
As Salvo said, "The problem is caused by the fact that
subsurface forked some libraries and made them incompatible, without
changing the name."

This isn't just bad, it's also quite hostile against the original
libdivecomputer... and sounds quite like the ffmpeg/libav debacle.



libgit,... well I'm not really into the subsurface code, but I never
understood why you introduced that as a storage backend.
Even the most prolific divers I know don't have more then 30k-50k
dives, and usually these people stopped logging there day to day dives
decades ago.
Using a plain XML file or poor-man's DB like sqlite should be more than
enough ... plus it would have the advantage that one can actually
manually edit/parse the log without big problems.
I had a few cases where I manually needed to merge dives and realign
their timestamps... too rarely to write a proper code for handling such
cases, but simple to script with a backend like XML.

libmarble,... I would rather not have a fancy globe at all and
therefore the program packaged properly in the various distros.
Actually there are even many more divelog related features one would
miss much more (logging of the used equipment, attaching/linking
pictures, logging of divecomputer [firmeware] settings, etc. pp.) than
a map.

libdivecomputer:
Wasn't the whole idea of it to have a _central_ FLOSS lib which allows
any program to easily access dive computers instead of having one piece
of different lib/code (each with different API) per model?
Now we basically have the same again,.. the "official" libdivecomputer
and the subsurface internal fork?!
Also, Robert said, the problem is that the original libdivecomputer
isn't too fast, right?
I'd guess the ABI itself doesn't change daily in such lib, and if the
distro packaged version is older and supports fewer computers... who
cares?
And let's be honest,... dive computers aren't smartphones. There isn't
a new model every week.



> There are four libraries that we want to control
Then - even if the alternatives I've named above would be probably
better - properly fork them.
For libdivecomputer you have even good chances that your fork would
become the main fork.

And distro maintainers have at least somewhat better chances with their
work. (I still could imagine that the release managers and security
team wouldn't be all to happy about such forks).


> 
> So that made me curious. There is a sum total of ONE email from you 
> on the
> mailing list, the beginning of which I'm quoting here:

Uhm I hade quite a number of bugs/enhancement[1] ideas open in track,
some of them fixed some of them not... we two even communicated several
times over some of them.

Actually I couldn't even remember that I used the ML the one time.


> That will give you the reduced user experience that we are trying to
> avoid.
Well, better some than no experience at all, right?
The later which is especially bad for all those people who thought that
subsurface would be something that is here to stay and have now all
their logs in it.
:-(


>  You are of course welcome to do that. We would appreciate if you
> didn't call it Subsurface if you did that, though.
Is it already trademarked and patented?! ;-)

Reminds me a bit to Mozilla, where the lawyers may have already knocked
on your doors when you changed a line of code and still named it FF.
O:D


> About 15% of our users are on Linux - this has been fairly consistent 
> for
> the past two years during which I have been trying to track those 
> numbers.
Again, I'm a bit curious how you track those numbers? Does subsurface
phone home?
Or is it by downloads (which again would likely be biased - because why
should Linux users download a package, when they have it in their
distro)?


> And since none of the native dive logs are running on Linux (and the 
> other
> dive log software that appears to exist under Linux is, frankly, a 
> joke
> and not really usable), my guess is that Linux users are much more
> motivated to use Subsurface than Windows or Mac users (where there 
> usually
> is a vendor app and of course there are other vendor independent dive 
> logs
> available like MacDive and DivingLog).
I haven't said that Linux users weren't motivated to use subsurface...
actually that was just my point, when I said that you make it much
harder for them now to use subsurface - they typically have no
alternative.


> If you have a solution that would allow us to tightly control about a
> handful of libraries that we link against that would work for Debian
Several options have been named,...


> I'll
> be happy to work with you.
Well in then end it wouldn't be me you'd have to work with but the
current/previous maintainers of subsurface of Debian.
And at least I - from my PoV - could understand if they're no longer
keen on working with a upstream which basically said he doesn't want to
have distros ship his program and to emphasise this wish he'd even make
their lives harder to do so.


> (yet it's the
> underlying
> mechanism that we use for our upcoming cloud storage feature in 
> Subsurface
> 4.5)
JFTR: I wouldn't want all my dives to be spied upon in the cloud :) ...
so if that was going to be a core / unavoidable part of subsurface, I
would anyway loose my interest.


Best wishes,
Chris.
(who is actually about to head into a one month vacation of tec
diving,... now unfortunately without a diving log software :-( )


[0] btw: funny that the subsurface side complains about something
hardly usable from "outside" (i.e. when not being the the main marble
program), while they actively try themselves to make using their stuff
more difficult for others :D

[1] #180, #181, #192,#193, #194, #198, #440, #453, #454, #649, #672,
#684
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-running-devel/attachments/20150826/fa9172a1/attachment-0001.bin>