Hello André and list,
On Thu, 2010-04-22 at 15:04 +0200, Andre Espaze wrote:
> 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.
...
The current package organization is a "legacy" system from back when I
first started to package version 3.2.6. It's really not very good. :-)
> I am aware of my ignorance on Debian package policy,
Debian package policy doesn't require any particular organization, it
just indicates what should be in shared lib, python, etc. packages.
> 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)
I like this organization. It's something like the transition we did for
Open CASCADE a couple of years ago, led by Jason Kraftcheck and Denis
Barbier. [1]
[1] http://lists.debian.org/debian-science/2008/01/msg00013.html
I have a few suggestions:
* There are a lot of "[T|t]est*" binaries in the salome package.
It would be good to separate these out into salome-core-test
etc. packages so one doesn't need to install them along with the
main binaries.
* The shared libraries should go in their own packages, such as
libsalome-core etc. Because their interface changes with every
version, they should probably change from the 0.0.0 version
designation to using the libtool "-release" flag with the
package version, e.g. libGLViewer-5.1.3.so .
* I think there should be a package called plain "salome" with the
core functionality which people expect to have when they think
of Salomé.
* The documentation also desparately needs to break up! I suggest
salome-doc for the non-built docs, and salome-user-doc and
salome-dev-doc for the docs made with "make -C [MODULE]/doc
usr_docs" and dev_docs respectively.
* As for implementation, instead of SALOME_MODULES, perhaps we can
have SALOME_CORE_MODULES, etc., and install them with DESTDIR=
$(CURDIR)/debian/salome-core or -advanced etc., and then move
around the shared libs, header files, symlinks, and python files
from there.
> 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.
I agree this would not be a helpful solution.
> In conclusion, is it worth to wonder about a new Salome package
> organization?
Definitely! Thanks for the suggestion. It will all take a lot of work,
and should probably happen after the initial package goes into unstable,
but it will make people's lives much easier in the post-squeeze release.
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
Attachment:
signature.asc
Description: This is a digitally signed message part