Re: Package available (was Re: Micro Manager)
Andreas Tille <andreas@an3as.eu> wrote:
>
> [Maintainer of 3rd party Fiji Debian package in CC
> Mark, at the Debian Med list we are currently discussing ImageJ /
> Fiji issues which might be interesting for you. The discussion
> might be interesting for your from here:
> http://lists.debian.org/debian-med/2011/11/msg00000.html
> ]
Thank-you, I appreciate it.
> On Tue, Nov 01, 2011 at 07:53:02PM +0100, Johan Henriksson wrote:
>> fiji is being maintained in a 3rd party repository:
>>
>> http://fiji.sc/wiki/index.php/Downloads
>
> Hmmm, the page says:
>
> Packages for Debian / Ubuntu
>
> <bold>
> These packages have not been extensively tested, so feedback
> to mark-fiji at longair.net would be very much appreciated.
> </bold>
>
> Such 3rd Party repositories are not really what I usually trust in the
> first place.
(I've removed that warning and updated that page now - it was a
bit out of date.)
There are two repositories for Fiji that I'm maintaining, stable
and experimental. I've been only being updating stable once
I've tested a set of packages from the experimental repository,
and since I rarely have time for that, it doesn't get updated
very frequently. The experimental repository is automatically
built on a weekly basis.
>> There is only one imagej debian package and it is based on the "original"
>> imagej from http://rsbweb.nih.gov/ij/
>> and lacks all the extras that fiji includes. in particular, the fiji
>> package is very up to date.
>
> I admit that I do not push every imagej version but the Debian package
> in unstable is later than the latest Fiji release. I do not know what
> this finally means because I realised that ImageJ is quite frequently
> released and I do not build every release just because I do not see any
> profit for our users (for the moment). I simply assume that not every
> release is wanted by our users because they did not yet asked
> for it.
I suspect that the difference here is that Johan is using the
experimental Fiji packages, while you were looking at the stable
release.
Incidentally, a recent development that might be worth
mentioning here is that while Fiji used to use ImageJA (a fork
of ImageJ) it now uses upstream ImageJ, using javassist to do
some runtime patching:
http://groups.google.com/group/fiji-devel/browse_thread/thread/665104296931b6b7
[..]
>> I don't see why we should duplicate the effort,
>> with lower quality.
>
> Well, I had a (very) short look into the Fiji source package and must
> admit that from a packaging perspective Fiji could need some
> enhancements. I have downloaded the source package and if I would
> consider sponsoring it to Debian - what IMHO would be a reasonable thing
> to do if I understand Johan's wording correctly - the sponsee would need
> to work on several items. However, I could imagine that this is a
> doable thing and I wonder what you think about going for such an effort.
> From my perspective the advantage would be pretty clear, because Fiji
> would become much more visible to users of Debian and it would be put
> under Debian bug tracking control which finally would make it possible
> to leave out this "not been extensively tested" warning mentioned above.
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.
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:
* 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.
* 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.
* 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.
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
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.
regards,
mark
--
http://longair.net/mark/
Reply to: