Andreas Tille <[email protected]> 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/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
