[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Package available (was Re: Micro Manager)



Hi Mark,

On Thu, Nov 3, 2011 at 5:14 PM, Mark Longair
<mark-debianlists@longair.net> wrote:
[...]
> It's been a long term aim of mine to get (at least some of) Fiji
> into Debian, and in fact I've intermittently discussed this with
> Steffen Möller.

Ok that's great news !

> Unfortunately, I believe that my current approach to creating
> the Fiji Debian packages is the wrong one, and it might be worth
> taking a paragraph or two to explain why.  One of the aims of
> Fiji was to create an easily installable package which bundled
> ImageJ with a large number of useful plugins, various JVM-based
> scripting languages, etc.  Essentially this was achieved by
> adding the source of all these plugins to the Fiji git
> repository, with major dependencies being added as submodules in
> that repository.  This has had the following problems for
> creating the Debian packages:

This really looks like debian-med goals for most of its package...

>  * The source of all these plugins (with widely different or
>   undetermined licenses) have ended up mixed into one
>   repository.  In building Debian packages I have to split the
>   build products from this one source tree into separate
>   packages, and for each package try to work out the authors
>   and licenses.  There has been an attempt to keep a track of
>   the licenses for each plugin in the LICENSES file, but this
>   isn't designed to be machine readable or easily mappable to
>   the build products, so this is painstaking manual work.
>   Those plugins that I haven't yet classified in this way just
>   go into a "plugin soup" package called fiji-plugins, which
>   currently has 82 jar files.  The amount of work involved in
>   going through these remaining plugins would be quite
>   considerable.

ok point taken.

>  * I've tried as far as possible to replace components from Fiji
>   with dependencies on existing Debian packages.  However,
>   whenever developers update libraries in Fiji to versions that
>   are later than those packaged in Debian, I have to switch
>   back to creating a Fiji-specific version of that package.
>   This is the case, for example, with Weka, Jython, jfreechart
>   and commons-math.

Did you fill bug reports in debian bts for those issues ?

>  * The Fiji source tree contains a number of binary jar files
>   without corresponding source.  The bio-formats submodule is
>   particularly concerning, since it's an important library in
>   general for biological image processing, and the source tree
>   currently bundles 24 jar files which should be external
>   dependencies.

Tell me about it ;) see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641448

Any help is welcome :)

> Although it pains me to say so, given the amount of time I've
> spent on this already, I'm not convinced that trying to build
> fine-grained packages out of the Fiji source tree is likely to
> meet the quality requirements for Debian main any time soon.  It
> would probably be better on building up a similar set of
> packages based on the existing Debian imagej package, but
> starting from upstream for each particular plugin.  (Where
> components only exist in fiji.git I can extra them into a
> standalone repository with git-subtree.)  Although it would take
> a long time to build up the same number of plugins as are
> bundled in Fiji, at least steady progress could be made in
> introducing useful packages into Debian.  For a number of

Sound like a plan !

> packages it doesn't make sense that they should be built out of
> the Fiji source tree anyway (e.g. bio-formats, RSyntaxTextArea,
> AutoComplete) since they're generically useful libraries outside
> context of Fiji.

How many people are behind the fiji effort ? Are they mostly
debian-based system users ? Jumping in the debian-med effort is
relatively easy.
I do not believe debian-med could get even close to the momemtum
involve in the fiji packaging, since it involve careful review of each
and every single source code to check licensing issue. But I can
imagine there is some duplicate work, and we could use some of your
help, if you wish to jump in.

2cts
-- 
Mathieu


Reply to: