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é
Reply to: