Re: netcdf uploaded (Re: Package available (was Re: Micro Manager))
Mathieu,
On Apr 11, 2012, at 11:10 AM, Mathieu Malaterre wrote:
> Josh,
>
> On Wed, Apr 11, 2012 at 10:53 AM, Josh Moore <josh@glencoesoftware.com> wrote:
>> On Apr 10, 2012, at 12:13 PM, Mathieu Malaterre wrote:
>>> On Mon, Jan 16, 2012 at 6:37 PM, Mark Longair
>>> <mark-debianlists@longair.net> wrote:
>>>> Hi Mathieu,
>>>>
>>>> Mathieu Malaterre <mathieu.malaterre@gmail.com> wrote:
>>>>>
>>>>> Hi Mark !
>>>>>
>>>>> On Sat, Jan 7, 2012 at 1:35 PM, Mark Longair
>>>>> <mark-debianlists@longair.net> 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
Reply to: