[Neurodebian-devel] Packaging EEGLAB

[Michael Hanke]

Hi Philip,

On Mon, Nov 10, 2014 at 12:48:53PM +0100, Phillip Alday wrote:
> I'm (slowly) starting work on packaging a modern release of EEGLAB and
> have put some thought into the best package architecture. Modern
> EEGLAB uses plugins extensively and having packages for the plugins
> avoids issues with MATLAB's path and write permissions.

Thanks for the detailed outline.

> I was thinking about modelling the structure roughly after Python's
> packaging, something like:
> 
> eeglab (defaults to most recent eeglab)
> eeglab13
> eeglab12 (maybe)
> eeglab11 (already there, so it would be nice to provide a clean
> upgrade path)
> eeglab-plugins-io (metapackage for the following IO plugins)

This seems reasonable to me. As for the long list of plugin packages,
I think you should consider a few questions:

1. Do the plugins come from the same source tarball? If so, we are
   talking about binary packages here.

2. Valid reasons for splitting stuff into multiple binary packages are,
   for example, heavy dependencies of only a subset of the plugins.
   Large size (>20 MB is my personal threshold). Licence differences
   (some are free, some are not) with implications on the archive
   section that can go in (main, contrib, non-free).

Unless some of these criteria are fulfilled splitting EEGLAB into many
binary packages is a tedious task with little benefit. I may be wrong,
though...

> Two further useful plugins that are common but not yet listed via
> EEGLAB's GUI are:
> 
> eeglab-plugins-erplab (or should this package be called simply
> "erplab"? The modern versions are clearly inteded as EEGLAB plugins,
> but the ERPLAB people want a separate registration and require a
> citation of their Frontiers article as part of their license)

That is clearly a 'non-free' licence and would warrant a different
package.

> eeglab-plugins-amica (depends on AMICA)
> amica (Adaptive Mixture ICA from Jason Palmer, capable of running as a
> standalone program)

External dependency here -- not in Debian, it seems -- could be
separated.

> And a plugin that sadly never got the love it deserved:
> 
> eeglab-plugins-cudaica (This will probably exceed my current knowhow
> and time constraints -- it requires the nVidia CUDA toolkit and
> patching the EEGLAB sources. See http://liaa.dc.uba.ar/node/13 and
> http://www.hindawi.com/journals/cin/2012/206972/)

The CUDA tools are definitely heavy and warrant a dedicated package.

> EEGLAB "expects" that plugins are in the plugins folder, so a first,
> obvious question is whether the eeglabX architecture will work well
> with plugins. Any suggestions on this or general package schema? When
> I need a break from writing my dissertation, I'll start packaging the
> core and the plugins I use, and expand to other packages after I
> submit. :-)

If there is a chance that plugins need versioned dependencies on EEGLAB
this would need to be built-in from the start. Maybe versioned plugin
packages are necessary -- hard to tell for me.

> The ANT EEP plugin is built against libeep, and I saw recently on the
> mailing list that somebody else is bundling libeep with their package.
> If this is the same libeep, I would be willing on cooperating on
> getting that bundled. Otherwise, I'll have to rename libeep to libanteep.

So this is just a name clash, or the same library?

> EEGLAB is GPL'd, but the license for many of the plugins is not
> exactly clear beyond "free as in beer". What do I need to watch out
> for here? AMICA is especially interesting because it includes binary
> components with builds for various platforms but currently no source
> distribution.

Ah, that is unfortunate and clearly non-free. It could still be made to
run (along the lines of the flashplugin-nonfree), but I'd carefully
consider whether you what to invest the necessary time to provide
functionality that cannot be fixed on the distribution end if broken.

Thanks again for your effort,

Michael

-- 
Michael Hanke
http://mih.voxindeserto.de