Re: Question on Salome package organization
Hello Adam, Thank you very much for your detailed reply, I am glad to see that we share the same views on the Salome package organization. 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. I agree with all those points. 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. Great! How do you imagine the Debian building of such packages? Should we keep the actual debian/rules with the complete source code and list precisely files for every package in the debian/*.files? Or should we split the source code between core, advance and dev and have several debian/rules but easy to write debian/*.files? With kind regards, André -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100505081131.gc20...@crater.logilab.fr
Re: Question on Salome package organization
On Mon, Apr 26, 2010 at 11:07:18PM +0200, Sylvestre Ledru wrote: Well done for this packaging! Yep, nice job. One more argument: we could plug Aster into Salome thanks to pylotage. If we are lucky, it could even make it for Squeeze! +1, let's try to get it into squeeze. It will mean more users and developers, even though the packaging changes completely for squeeze+1. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100427073631.ga4...@volans.logilab.fr
Re: Question on Salome package organization
On Tue, 2010-04-27 at 09:36 +0200, Nicolas Chauvat wrote: On Mon, Apr 26, 2010 at 11:07:18PM +0200, Sylvestre Ledru wrote: Well done for this packaging! Yep, nice job. Thanks. One more argument: we could plug Aster into Salome thanks to pylotage. If we are lucky, it could even make it for Squeeze! +1, let's try to get it into squeeze. It will mean more users and developers, even though the packaging changes completely for squeeze+1. Done! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Question on Salome package organization
Greetings again, salome 5.1.3-6 is up at http://lyre.mit.edu/~powell/salome/ . The package is big and ugly and kludgey, but I've tested it a bit and confirmed that it runs from the menu. I built it with -sa and closed the ITP bug in the changelog, so it should be ready for its first upload. The question is: should I upload it? Here are the arguments as I see them. For uploading: * It seems to work (run), and thus can meet users' needs * Quicker reply from ftp-masters on copyright and other uploading issues * Broader testing, especially if it gets into squeeze * Possibly more devs interested in helping with debugging and package development * Use of the BTS to track issues * It will take a lot of work to fix some of the issues below, let's work on them together Against uploading: * The package is buggy! In particular, module loading requires .so files, so one needs to install about 100 MiB worth of -dev packages in order to run it * Package layout is not finalized, as demonstrated below * Shared library versioning isn't even finalized... In short, I think this package is about where OpenCASCADE and OpenOffice were when first uploaded: crude and simple packaging of a very useful piece of software, with plans for big packaging changes. I'd like to go ahead and upload in about 24 hours unless anyone has a strong objection. -Adam On Thu, 2010-04-22 at 19:23 -0400, Adam C Powell IV wrote: 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
Question on Salome package organization
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é -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100422130415.ga10...@crater.logilab.fr
