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 source tools
http://www.opennovation.com/
Attachment:
signature.asc
Description: This is a digitally signed message part