Question on Salome package organization

[Andre Espaze <andre.espaze@logilab.fr>]

Dear list,

Now that salome-5.1.3-5 is running, I started a documentation on its
content and finally found a question on Debian package organization.

Salome is delivered with many modules that could be classified under
three categories: usual pre and post processings, advanced uses and
developer assistance. As a consequence, the Salome default command only
tries to load the usual modules. Does it make sense to follow this
organization in Debian packages? The first sections will introduce
every category while the last one makes a comparison with the current
implementation.

Relevant modules for usual pre and post processing
--------------------------------------------------
By starting with the command::

    $ runSalome

the following modules should be loaded:

    - KERNEL, the CORBA core services
    - GUI, the main graphical user interface
    - GEOM, for creating geometries
    - MED, for reading and writing files containing meshes and results
    - SMESH, for creating meshes
    - YACS, for coupling simulation systems
    - VISU, for analyzing results

Currently, the runSalome command does have this default behavior.

Advanced uses
-------------
Such modules will be useful for advanced use cases:

    - MULTIPTR, for partitioning meshes

The following modules add new mesh creations:

    - NETGENPLUGIN
    - GHS3DPLUGIN
    - GHS3DPRPLUGIN
    - BLSURFPLUGIN
    - HexoticPLUGIN

However the four last plugins require non-free librairies so they are
not part of the Debian packages.

Modules for developers
----------------------
Those two modules assist the Salome developer:

    - HXX2SALOME, a Salome component generator
    - XDATA, simplify classes and GUI creations

Those two modules interact with other services and provide a functional
example by calculating Sierpinsky fields:

    - RANDOMIZER
    - SIERPINSKY
    
Those modules do not really add functional examples but provide useful
insights for adding a module to Salome:

    - LIGHT, for running Salome without CORBA
    - PYLIGHT, Python version of LIGHT
    - COMPONENT, several examples on the Salome architecture
    - HELLO, a starting example
    - PYHELLO, Python version of HELLO
    - CALCULATOR, another starting example
    - PYCALCULATOR, Python version of CALCULATOR


Comparison with current implementation
--------------------------------------
The current Salome installation delivers all modules but is splitted
into 5 packages:

    - libsalome
    - python2.5-salome
    - salome-common
    - libsalome-dev (currently required by default because of a bug)
    - salome

An extra package provides the documentation:

    - salome-doc

However installing libsalome, python2.5-salome or salome-common alone does
not meet any use case because their content is not indepedent. You 
finally need the commands inside the salome package for starting CORBA 
services even if the graphical user interface is not used.

I am aware of my ignorance on Debian package policy, but I would suggest
such kind of organization:

    - salome-core (the usual pre and post processings)
    - salome-core-dev (its development files)
    - salome-advance (the advanced uses)
    - salome-advance-dev (its development files)
    - salome-dev (every module for the Salome developer with
    development files)
    - salome-doc (the actual documentation)

Another solution would be to provide a package for every Salome module
but it seems to be confusing because of the modules number. Moreover the
package creations is going to become inconvenient while producing very
little improvement to the user. Who is going to create a mesh without
using the GUI but only through a CORBA service (thus installing only
salome-kernel and salome-smesh)? The same scenario can be repeated to
others modules as well.

In conclusion, is it worth to wonder about a new Salome package
organization?

All the best,

André