Mathieu, On Apr 11, 2012, at 11:10 AM, Mathieu Malaterre wrote:
> Josh, > > On Wed, Apr 11, 2012 at 10:53 AM, Josh Moore <[email protected]> wrote: >> On Apr 10, 2012, at 12:13 PM, Mathieu Malaterre wrote: >>> On Mon, Jan 16, 2012 at 6:37 PM, Mark Longair >>> <[email protected]> wrote: >>>> Hi Mathieu, >>>> >>>> Mathieu Malaterre <[email protected]> wrote: >>>>> >>>>> Hi Mark ! >>>>> >>>>> On Sat, Jan 7, 2012 at 1:35 PM, Mark Longair >>>>> <[email protected]> wrote: >>>> [..] >>>>>> NetCDF Java itself also bundles a huge number of jar files in >>>>>> the source distribution, but to build the core of NetCDF you >>>>>> actually need relatively few dependencies. I made a package >>>>>> that builds just the core of NetCDF (i.e. the makeCore ant >>>>>> target) and only relies on Debian-packaged dependencies. (The >>>>>> NetCDF core is all that bio-formats requires, I believe.) That >>>>>> repository is here: >>>>>> >>>>>> https://github.com/mhl/libnetcdf-java >>>>> >>>>> Cool. I'll import that into the debian-med svn if this is ok with you: >>>>> svn.debian.org/svn/debian-med/trunk/packages/netcdf-java >>>> [..] >>>>>> The repository with my Debian packaging of bio-formats is here: >>>>>> >>>>>> https://github.com/mhl/libbio-formats-java >>>>> >>>>> cool. If this is ok with you I'll import this into debian-med svn at: >>>>> svn.debian.org/svn/debian-med/trunk/packages/bio-formats >>>> [..] >>>> >>>> That's great in both cases - thanks for doing that. >>> >>> ref: >>> http://ftp-master.debian.org/new/netcdf-java_4.3.8-BETA-1.html >>> >>> Assuming everyting goes smoothly, I can now move on to bio-formats itself. >> >> Hi Mathieu, >> >> Looking at Mark's repo (mhl/libbio-formats-java) and the patches under >> http://anonscm.debian.org/viewvc/debian-med/trunk/packages/bio-formats/trunk/debian/patches/, >> much of what was necessary was to remove the jars and configure the build >> for using /usr/share, a source drop, etc. Would it help if we modified the >> build so there's a global switch (e.g. ant -Ddebian=true) to allow these >> commits to live in the mainline? > I am not too keen on the whole "-Ddebian=true". Even if I only use > debian distribution, there are other distros out there. Also this puts > the burden of maintaining debian related material outside of debian > organisation. I do not believe this will be beneficial for both > communities. > Instead what I have been trying to do is simply use the documented > 'build.sysclasspath' [1], ant option. Mark's solution was more > invasive even if he used json scripts to automagically fix ant build > files. > > So really as long as netcdf/bioformats allow use of > build.sysclasspath=first then all is fine with me. If that works on your side, it sounds like a fine solution, though we certainly haven't tested it that I know of. My personal preference (and mid- to long-term goal) would be to either modify the existing build to allow selecting between property sets or to use maven/ivy to do that selection. So "debian=true" above would actually be something more like: "ant -Drepo=usr-share" with the default being to use jars under artifacts. Some form of flag or state-detection would also allow handling remove_git.patch and Mark's patches around the OSGI target in the mainline. But, otherwise, separating the Debian concerns out makes great sense. > There are still a > couple of tiny patches but that was mostly me banging my head trying > to get things moving. I believe in the end the number of patches > should be much smaller. > > The only patch, I really dislike so far is the following: > http://anonscm.debian.org/viewvc/debian-med/trunk/packages/bio-formats/trunk/debian/patches/ij.patch?view=markup This one I'll leave for Melissa to comment on. > I guess I need to check if using newer imagej release this patch goes away. >> (Would the jars be allowed to remain unused, or must they be deleted to >> adhere to the Debian guidelines?) > Yes we are required to remove any convenient copy of > libraries, as per policy ยง4.13 > > http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles Understood. Roger pointed out the same to me just now: "the embedded jars would require deleting in the debian .orig.tar to sanitise it for distribution. Repacking the upstream source is typical in cases like this." >> Where possible we'd certainly like to make Debian packaging simpler. A new >> stable release of Bio-Formats (4.4) is planned for the summer which it would >> be ideal to target, giving us a chance to merge in patches and the bulk of >> Mark's work (especially having seen some of how he suffered!) > > Again the number of patch should really be minimalistic in the end. > >> I've CC'd Melissa Linkert, the Bio-Formats lead. Roger Leigh, a (previously >> non-Java) Debian maintainer who's recently joined the Bio-Formats project, >> is already subscribed to the list. > > The biggest issue is that I do not believe I will be ready for the > debian freeze (should happen before summer if I recall correctly). The > whole bio-formats packaging seems very difficult to me, this is why I > can only build a minimal number of targets right now: > > "jar-autogen jar-common jar-formats jar-jai jar-loci-plugins > jar-lwf-stubs jar-mdbtools jar-metakit jar-ome-xml jar-poi-loci" What are the issues you've run into for the other targets? Specific jars missing from Debian? > Thanks for your interest and CCing people to help out ! And thanks for > bio-formats ! > -M Gladly (on all fronts). ~Josh > [1] http://ant.apache.org/manual/sysclasspath.html -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
