Re: status of the opencpn PPA for inclusion in Debian
On 2015-03-21 13:42:51, Pavel Kalian wrote:
> On 03/21/2015 07:47 AM, anarcat wrote:
>> On Wed, Jan 07, 2015 at 08:52:55PM -0600, Pavel Kalian wrote:
[...]
>> 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.
> Well, that's the feature of Launchpad - it injects the dependency
> version for the target Ubuntu release and does not honor what we define
> in the control file. Maybe it can be overriden if we specify an exact
> version there, but I'm not sure. Will try.
I see, well in this case: don't worry about it, we'll fix this when we
upload to sid anyways.
> Anyway, as a Testing user myself, removing wx2.8 surprised me "a bit"...
Yeah, that's weird. I haven't investigated why it happened...
[...]
>>> 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.
> There are no library binaries involved in Linux build/packaging in the
> source tree at all.
> The wx DLLs in the tree are not used in the build at all, they are just
> convenience for packaging on Windows.
> The only binary lib used in any build is the Windows crashreporter - is
> it a problem for Debian packaging when it is not at all involved? If it
> is, we can of course bundle the source, but it will just mean more
> completely unused stuff in the tree.
Source-less files will be a problem for the FTP masters, that is
certain. We will need to either remove the binary files or include the
source.
[...]
> The bundled libs are not used in Linux build at all, we link against the
> system libs. But they are obviously required on Windows. For the
> packaging purposes, they can be stripped if it makes sense.
They need to be stripped if no source is provided, for sure.
[...]
> It is possible to build against wx3.0 on all platforms (We currently
> build against it just for OS X and Android, where it is inevitable,
> though). There is a problem with the complete switch - wx3.0 has no
> backport for Ubuntu Precise as far as I can tell, neither in the
> official repos nor anywhere on Launchpad, which means we would have to
> provide our own backport in the PPA or make the users install from
> elsewhere, which is quite a PITA and would generate way more support
> traffic than living with the Jessie "problem" for now.
Maybe we can have the two packages diverge (between ubuntu and Debian)
at that level. Eventually, those differences would go away as 3.0 gets
propagated everywhere...
> It would also mean rebuilding all the plugins. Quite some work. Said
> that, we would like to migrate to wx3, but not with the current 4.0
> release (as it looks now, there will most likely be just one maintenance
> release in this cycle with a couple of minor fixes). 4.2, out in ~6
> months is the target for now.
Understood. However, if 4.0 can be built against 3.x right now, we could
just upload that in Debian without changing things upstream... It would
be easy enough, from what I understand, just a tiny patch to change
dependencies on the control file maybe?
[...]
>> And to be real clear, I would be happy to sponsor your package once it:
>>
>> 1. doesn't compile against convenience copies
> As far as I can tell this is addressed for a long time already. For the
> build on Unix platforms where the libs are available and cmake can find
> them.
Awesome. The debian/control build-dependencies should handle that.
>> 2. doesn't ship binaries without source
> Is the windows-only crashrpt library a problem here? If so, we of course
> can include the source. Or can we just link to
> http://crashrpt.sourceforge.net/docs/html/index.html in the docs?
> Do we have to provide wxWidgets source just because we have to ship the
> libraries on Windows and Mac?
> Anyway, all of it can be stripped from the tree for packaging on Linux
I am not sure. Maybe other DDs (in CC) can provide feedback here, but I
would recommend providing a smaller tarball with only the OpenCPN source
code. First it takes up less space on all the mirrors, and second it
will make the FTP master's job easier.
But my gut feeling is that binaries without source *will* be a problem,
even if the software is free (like say wxWidgets).
[...]
>> Do you think the current package fits those requirements?
> I will implement the stripping of all the Linux-irrelevant stuff in
> https://github.com/nohal/launchpad/blob/master/publish.sh so we have a
> baseline to finish it off.
It would be great to see this as part of the debian package
directly. Earlier in this bug report, I have made a "get-orig-source"
target in debian/rules for exactly that purpose. This is common practice
that should be followed here - although it may conflict with the
multi-source-package approach that seems to have been taken...
Nevertheless, it is important (but not compulsory) that the tools to
build the tarballs from upstream are available or at least referenced in
the source. A common place to document this is debian/README.source.
(Sorry if i'm stating the obvious.)
I am really glad to hear your feedback so quickly, things are looking
pretty bright for getting OpenCPN in Debian.
I believe the next step is to produce a tarball without sourceless
binaries (or with the sourceless binaries's source ;).
Thanks again!
A.
--
We should act only in such away that if everyone
else acted as we do, we would accept the results.
- Kant
Reply to: