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

[Christoph Anton Mitterer]

On Wed, 2015-08-26 at 09:05 -0700, Dirk Hohndel wrote:
> Some of us have expressed our dismay with the way distributions work
> these days.
Well to be honest such dismay comes usually always from the same
fraction within open source... which is typically exactly that fraction
which tries to put more and more control over what the user does and
what he (should) want.

Quite often this fraction styles itself as the "modernists" which
allegedly bring fancy and blessed technology to opensource, like cloud.
And also quite often, what this fraction pushes for is in reality a
major step back, security wise, and especially when it comes to longer
term questions of freedom of users.

That being said, the way distributions work is still considered by many
(if not the vast majority) to be simply the way it should be.
You may not get they hype with it as when you have a fully totalitarian
ruled appstore with some fruit logo on it,... and you may not fully
expose your user's data to all kinds of criminals and agencies, as when
you put everything in the cloud or even worse run programs directly
from there - but therefore you get a system based on proven paradigms
which are amongst the main reasons why open source software is so
successful and often simply superior.

> 
> But let's get real here. We are not "hostile against core paradigms 
> of the
> FLOSS community".
Well but in fact you seem quite close to be:
- You don't want distros to use the software as they wish (like using
  an old version, or properly using the system libs (as nearly all
  other projects manage to do)) so you even openly say that you work
  against distros shipping it.
  Doesn't sound quite friendly towards the community, does it? And
  even if you'd now argue again "well distros are conceptually broken
  and thus they're not the 'community' we wish - it still limits the
  freedom of users, cause shipping a program properly as part of a
  distro, even if upstream doesn't want that to happen, is still part
  of that freedom.
  Of course you can always argue like "People can just fork" or "the 
  license still allows it", but that's merely a sticker of "we're
  free/open then", not real freedom/openness and thus it's quite
  obvious hostility against core paradigms.
  As I've said before,... it's the Oracle way of OpenSource, put a OSS
  license on it, lock out the community, fully control the whole
  lifecycle of the project and regularly step on all users toes.

- You argue with the "user experience"... so basically, everyone who
  doesn't to as you define what the current experience is, should
  either stop so or for&rename.
  If all projects would behave like this, pushing their wishes trough
  regardless of other (whether majorities or minorities), we'd
  probably have millions of forks, and the whole idea of FLOSS would
  be dead.
  That's basically the GNOME/Mozilla way of open source, a la "we
  provide a product, like it as it is, if not, go away... and if we
  break with long standing and proven behaviours... either like what
  we give you go away,..."
  Well in the GNOME case many people went away ;-) which is why we
  have Cinnamon, et al.
  
  This kind of arguing (i.e. with the "experience" you'd need to
  protect for the sake of the users) is actually the most hostile part
  against FLOSS here.
  Below you complain that Debian shipped old versions (for which it
  has quite some reasons, i.e. the idea of stableness,... and which
  you as upstream probably provoked as well, by making subsurface more
  and more difficult to package, unless of course you're happy with 
  providing an installer blow which ships at least parts of it's ext 
  dependencies with it).
  Which version a distro ships is in most cases (there are some
  special exceptions) none of upstream's business. It's part of the
  freedoms one should get by FLOSS.
  What comes next? That one could argue "our products experience is
  destroyed if it's shipped in an non QT desktop environment"? Or "you
  must not change the maps provider e.g. to non-OSM-whatever, as it
  destroys the experience"?
  Will future versions of the binary subsurface have a internal update
  system that nags every 10 minutes to update, because they use a
  version which no longer matches the current experience?
  
  Arguing with the user experience sounds all to familiar to what evil
  greedy companies like MS/Apple/etc. do. Fully controlling
  everything, pushing out competitors or non-endorsed usage models...
  and all of course just "for the sake of their users".

  And yes, you're not doing this (yet),... but the way you argue is
  just that. Having the sticker of "GPL" attached to some piece of,
  code alone doesn't make it free yet - sure everyone could fork
  subsurface, but as said before this is more theory than practise.

- Shall I continue? I guess not...


> The catholic church had the crusaders, Islam has ISIS, the open 
> source
> community has their extremists. Neither of those extremist groups 
> speak
> for the whole community. You do not speak for the open source 
> community.
> I don't either. Neither do I claim to do so.
And neither did I.
Yet we all know that some things are most probably beyond the paradigms
and bad (well at least within some of those religions)...like beheading
innocent people, or running a plane into a skyscraper.
And one doesn't need to be the speaker for all to be able to realise
this and it's still true even if god (which would probably be that
Finnish PADI diver living somewhere in Oregon, in case of the kernel)
would claim so.


> I'm sorry we mislead you.
Well I haven't said it was done on purpose... :)

>  I don't quite understand how we mislead you. I
> don't quite understand how data in our open XML format is similar to
> spending money on a DLSR - but I guess we have by now well 
> established
> that we are talking past each other.
Isn't it obvious? The DSLR company changes a major part of their
systems (like you change subsurface from being reasonably
distributable), like the mount and the electrical stuff there.
I can no longer use my old but still good lenses on new camera bodies
(like I cannot use my subsurface data in future Debians).

Of course you can argue: "you have your open XML format, just convert
it to whatever you want"... but while I can easily do it, not every
user may have the necessary skills.
It's the same with the cameras and lenses,... typically you can always
find some way to mount older lenses on a newer camera,... but it's
quite some effort and you always loose something (like functionality
and/or quality).

For the camera manufacturer, the misleading part would have been their
promise that this is the new mount which is here to stay for decades to
come (ask Olympus users, they know what I'm talking about ^^)... for
subsurface it would have been the implicit assumption by common sense,
that - unless otherwise noticed - it would behave like most other sane
FLOOS project, e.g. not forking libs without renaming them... and not
actively working aginst distros shipping it.


> We have asked SPECIFICALLY Debian to stop providing an out-dated
> version
> of Subsurface to its users as that caused confusion and problems for 
> our
> users and support burdon for us.
Well I've already mentioned above that it should be none of any
upstream's business which versions a distro ships and also which
version a user has installed.
Or would your users of your binary installers get into troubles when
they don't want to update anymore?

Of course, however, you're absolutely free to deny support for outdated
versions... and point people to the distributor instead.
I thought that would be normal and every end-user would understand
this.


>  Debian was unwilling to follow our
> choices of open source components that we used.
"Unwilling" ... well if you put people obstacles in their way to follow
proper policies o.O
Plus you shouldn't forget that Debian *is* a community project, so even
if you wouldn't have that issues with your internal library forks, it
could still simply be a matter of manpower that the current version of
subsurface wasn't packaged.


>  So we asked Debian to drop
> bundling Subsurface since we provide a version of Subsurface which a 
> diver
> who happens to run Debian and wants to use Subsurface can install.
Well I guess most experts would probably discourage their users from
doing so for compatibility and security reasons.


> Here's the funny thing. There aren't a lot of options for a diver 
> looking
> for a decent open source dive log. But there are a TON of options for 
> a
> diver looking for an OS that supports her needs. And the numbers that 
> we
> have clearly show that a tiny fractions of divers seem to think that
> Debian is their best choice. And the audience for which Subsurface is
> being developed is divers, not Debian maintainers.
Well you still haven't told where/how you get your numbers from :-)

As mentioned before, non of the divers I know (except for one single
case) wouldn't even know what Linux/Debian/opensource or subsurface are
and simply use the original software for their DC.
And that single exception has some 15k of dives on his back and stopped
logging like 10 years ago ;)


> XML still is the default storage format.
Ah nice :)
Well that's basically the main reason why I joined the discussion, even
if that part fell a bit low:
Simply disabling the libgit parts may be a way for the Debian
maintainers to keep up with an at least somehow "proper" packaging of
subsurface.
libdivecomputer could be counted as a special exception that is not
separately packaged and maybe even statically linked... and the "main"
libdivecomputer isn't used anyway by something else.
So only subsurface-marble would be left as a problem maker.

>  The git backend was added in
> preparation for cloud storage of dive data, which is in return one of 
> the
> key features needed before it makes sense to have an Android 
> application.
> 
> See, we are interested in what divers would like - and a full fledged
> Android app has been very high on the list of things people ask us 
> for...
> 
> And now I would have to tell people in the Android store "seamlessly
> exchange data with Subsurface 4.5 on the desktop (except Subsurface 
> 4.5 as
> shipped by Debian)". That's ridiculous.


> Demand? I have politely asked to respect our wishes. I can't stop you 
> from
> shipping a pile of dog poop and calling it Subsurface. All I did was 
> ask.
okay then s/demand/wished/g


> If by "properly packaged" you mean "broken and incompatible with
> upstream"
> then yes, you are right.
Apart from when one would want to use the Android software and cloud
functionality of subsurface - when exactly would it be necessary to be
"compatible with upstream" (in the sense of fully up to date)?


> They are screwed because Debian maintainers insist on removing
> features
> and refuse to accept upstreams choice of libraries we want to depend 
> on.
So much for "you just wish" and "don't want to control"... o.O
But seriously... I haven't read here that anyone of the former
maintainers ultimately insisted on removing features.
Sure they weren't all to happy with broken software design (i.e.
internally forked libs) but there was that post from Salvo where he
showed up a possible way when you'd have properly renamed your forks
(yeah call it "branches" or whatever you like... effectively they're
forks in this case).
He said that "Debian, as a general rule, disallows duplicated source
packages" but that doesn't mean that there can't be exceptions if
there's good justification (even if there's no good justification -
take the former situation with ffmpeg/libav).


> They are more than welcome to use the packages that we provide - or 
> switch
> to a more sanely run distribution.
> 
> I'm talking to the Fedora maintainer right now about getting 
> Subsurface
> packaged for Fedora 23.
I'm kinda confused now... in the previously mentioned list post, you
wrote that you actively work against making packaging subsurface within
distributions, quoting:
"we'd much rather have distributions drop Subsurface"... "in a
way to intentionally prevent distributions from shipping Subsurface"
Now you say you don't and distributions are welcome, as long as they're
run "sanely"?!

So it's basically just Debian which you don't want to ship subsurface
and with RH/Fedora it seems to be possible to match their policies (and
I'm sure they also have some policies about packaging)?!
Honi soit qui mal y pense!

Or does "sanely" mean for Fedora to have questionable code duplication
and forking without renaming? Then good night poor Fedora ;-)


> Actually I talked to Jef (the libdivecomputer maintainer) about this 
> and
> we agreed that this should just be a branch of libdivecomputer, not a
> fork. The repository from which you can get our version is named 
> libdc
> instead of libdivecomputer in order to avoid confusion, but it's 
> still
> just a branch in libdc - libdc master is the same as libdivecomputer
> master. Ironically libdivecomputer is even hosted on my 
> infrastructure.
To be honest I don't get it... why not just keeping both up to date as
one with a stable API? At least if you're really as open as you claim,
because wasn't this the idea of libdivecomputer? Having a generic and
dive computer library and not just something for subsurface?

Then distros could have used their system libdivecomputer, at most at
the expense of some models not yet supported,... which, as I've
mentioned previously, is a non-issue as new dive computers don't hit
the marked weekly.


Well long discussion,... thanks for it, but I guess I've lost all
interest (aka holidays-mode: doing real dives is much better than
arguing how to log them ;) )... so I'm out.


Cheers and thanks for all the fish, crustaceans and see snails ;-)
Chris.