On Wed, Jan 07, 2015 at 08:52:55PM -0600, Pavel Kalian wrote:
> Hi...
Hi Pavel,
> I'm an upstream developer and managing the PPA on Launchpad.
Thanks for chiming in! It's certainly a good way to try to resolve this
in the long run. :)
(and sorry for the delay, i wasn't in cc to the bug report so i didn't
see you reply until today.)
> It certainly is more messy than needs to be, but it serves it's purpose,
> which is to get the packages to the user in a way he can digest...
Yeah, and I can certainly appreciate that! I certainly appreciate
instructions on how to use this in jessie, for example. :)
For the record, on Jessie, i am able to install the package from the
Trusty PPA here:
deb http://ppa.launchpad.net/opencpn/opencpn/ubuntu trusty main
I do need to install wxwidgets from sid however, as mentionned in the
upstream instructions.
I would have been able to install the wxwidgets packages from wheezy
(which seems like a better option than sid IMHO) if the dependencies
were a little more relaxed (>= 2.8.12.1 instead of >= 2.8.12.1+dfsg).
Unless of course that's an actual hard dependency requirement.
> With the upcoming 4.0 release I have modularized the packages to certain
> extent, separating the docs, tide data and GSHHS shorelines as they are
> logical components.
That's great news. I haven't reviewed the result but that seems like a
huge improvement already.
> I currently do no effort to clean the .orig sources off stuff not needed
> on Linux, but it is on my list past the release.
Frankly, I don't think it's that critical. The most important point
right now is to ensure there are sources for all the binaries provided
with the package.
Code deduplication is a "should", not a "must" in Debian, IIRC,
especially if there are actually no other copies!
> We've put some effort into clarifying the license info etc. over time to
> make packaging for Debian possible, but without further feedback from
> you, finishing it in an acceptable way will keep having low priority -
> we simply lack manpower to study the requirements in-depth.
Understood. That seems perfectly reasonable. From what I understand,
most of the actual licensing issues are gone. According to a quick
review I did in october, all that was necessary was to remove copies of
wxwidgets, the .git directory, zlib, bzip and tinyxml. I believe those
were probably all "convenience copies of code" (ch. 4.13 in the debian
policy):
http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
So creating a tarball without those *should* be done, but it's not
absolutely necessary, unless there are still (for example) DLLs without
source. What is necessary however is the built package
should *not* use the convenience copies but link to the existing
libraries, to make security upgrades easy and (basically) possible.
Another nice thing would be to build against wxwidgets 3.0: is that
possible at all? A quick search led me to believe it is how opencpn is
compiled in Windows and OSX... Since jessie doesn't ship with 2.8
anymore (for reasons I cannot fathom), compiling against 3.0 means it
would be possible to backport to jessie and even, in fact, all the way
back to wheezy and squeeze, since those also have wxwidget 3.0
backports!
> Thanks for trying to clean up our mess
Well, to be fair, it's an amazing work you guys are doing. I'm just
sitting on the sidelines ranting that my computer isn't working the way
it should be. Sorry about that. :)
I hope my feedback here still has some use, and certainly hope to see
opencpn land in Debian at some point.
And to be real clear, I would be happy to sponsor your package once it:
1. doesn't compile against convenience copies
2. doesn't ship binaries without source
3. builds against 3.x (optional)
4. doesn't ship convenience copies of code (optional)
Do you think the current package fits those requirements?
In fact, I will need this package running in production fairly soon, so
it would make sense for me to push again in that direction. :)
Sorry we missed jessie. We can still make it to backports though. ;)
Hold fast,
A.