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/
signature.asc
Description: This is a digitally signed message part