subsurface: FTBFS in experimental

[Anton Lundin]

On 26 August, 2015 - Christoph Anton Mitterer wrote:

> On Tue, 2015-08-25 at 17:55 -0700, Dirk Hohndel wrote:

...

> > 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.
> 

Wtf. Have you even tried to build subsurface? Subsurface builds just
fine with Jef's libdivecomputer master. Stop whining about
incompatibilities that aren't there.

And, yes, subsurface has a branch of patches which Jef haven't accepted
upstream. They make lots of sense to subsurface, and thats why we
insist on subsurface being distributed to users include them.

And, no there is no hostilities between the top tree contributors of
libdivecomputer. There are some different points of views as in all
healthy projects, but as far as hostilities go, your're the most
hostile thing that exists to that project.

And, yes, Jef, Dirk and I are the top tree contributors to
libdivecomputer.

> 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.

Out of which ass did you pull that statement? My xml file was some
unpleasant 14Mb of data. 

And yes, the git based backend makes sense for the user story that a
user would like to have and edit their data on more than one machine /
device.

> 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.
> 

So, do you plan to write another storage backend which we can use for
multiple concurent offline edits? stfu until then.

And editing the data in the git-format is easier on the eyes than 
editing the xml. You use git mv on a directory to change the start time
of a dive.

> 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.
> 

So, you're now the one deciding on what the "user" wants and not?

You're free to fork the project then, but until then, whats the problem
packaging libssrfmarblewidget.so together with subsurface as we
suggested?

If you don't like to see the globe, hide it then, but don't break the
software for anyone who would like to use it.

> 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.
> 

Lots of users care, and yes, there are new dive computers on the market
about every month or so.

"Oh, hey, you can now update your firmware in your ostc devices with
subsurface, unless you're using Debian."


What a awesome experience for your Debian users, not.



//Anton - Who grew tired of arguing against more FUD


-- 
Anton Lundin	+46702-161604