On 03/21/2015 07:18 PM, Antoine Beaupré wrote: >>> 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... >> Maybe with some macros and ifdefs you could default to wx 3.0 but allow >> compiling with wx 2.8? > >From what I understand, it can easily be built against 3.0 already. It > may even autodetect whatever is there already. While it can be built, it is pretty sure there are issues in how it works with wx3 on Linux, it received very little testing upstream and certainly won't get any but totally trivial and safe wx3 related fixes in the 4.0 series. Master leading to 4.2 is a different thing, but currently alpha quality due to Android support landing. Until Precise reaches EOL it's support will get precedence over Debian as for upstream it represents more users with less skill, equaling to more support "costs" if it stops to be totally straightforward. >>> 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). >> Yes, that will be a problem. I would suggest doing this: >> >> Strip all the binaries and embedded code/data copies from your VCS >> repository (git/svn/cvs/etc). >> >> Automate the source tarball build process with the `make distcheck` >> target of autotools/cmake etc and just create a source tarball >> (opencpn-1.0.tar.xz) with no binaries or embedded code/data copies. >> >> Automate the Windows build process and have it download the requisite >> binaries at build time. Or if you prefer a Windows build without network >> build access, create a script to download the Windows binaries and put >> those in an opencpn-win32-dev.zip file that people can just unzip in the >> right place before starting the build. If a second unzip step is too >> much for people, you could produce a source tarball for the Linux >> distros and a source tarball with all the binaries for Windows folks. >> Personally I think Windows users probably don't want the source, they >> would just want the compiled binaries. > You said it brother, that is pretty much what I was thinking of. :) > > Thanks for your feedback pabs! > > a. > I would also love to live in a Debian/GNU centric world where Windows users don't think they can build packages from source without reading C++ for Dummies and OS X users that they use the only platform on Earth... Unfortunately I don't ;)
Anyway, I have modified the Launchpad packaging scripts to strip everything not needed for the Linux build while creating the source tarball, how can it be submitted for review? Or should I submit a patch for get-orig-source? Where and how (http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/trunk/ seems a bit out of date)? I suppose the data packages opencpn-doc, opencpn-gshhs and opencpn-tcdata should be usable in the same form they already have on Launchpad. Thanks Pavel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
