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