Hi, I see that the actual packaging work for getfem++ is being done here: http://svn.debian.org/wsvn/pkg-kde/krap/getfem%2B%2B/trunk/
Unfortunately the current packaging status fails to build the getfem++ code from the upstream svn-repository, mainly because of upstream autotools modifications. Hence, for the upcoming version 4.0 extra packaging work is necessary. My efforts on packaging a svn version of getfem++ from scratch (unfortunately not yet tested in Debian) can be found here: https://launchpad.net/~logari81/+archive/ppa/+files/getfem++_4.0~svn3056-0ubuntu0ppak6.diff.gz<https://launchpad.net/%7Elogari81/+archive/ppa/+files/getfem++_4.0%7Esvn3056-0ubuntu0ppak6.diff.gz> https://launchpad.net/~logari81/+archive/ppa/+files/getfem++_4.0~svn3056-0ubuntu0ppak6.dsc<https://launchpad.net/%7Elogari81/+archive/ppa/+files/getfem++_4.0%7Esvn3056-0ubuntu0ppak6.dsc> https://launchpad.net/~logari81/+archive/ppa/+files/getfem++_4.0~svn3056.orig.tar.gz<https://launchpad.net/%7Elogari81/+archive/ppa/+files/getfem++_4.0%7Esvn3056.orig.tar.gz> My packaging version doesn't use cdbs and uses python-support for the python modules. It also includes a new copyright file. Several minor issues have been fixed in collaboration with upstream. I would like to test my package on Debian too but first I would like to address some issues: 1. Packages names. My suggestion is the following: - getfem++ : source package - libgetfem4 : main lib - libgetfem-dbg : debugging package - libgetfem-dev : dev-package - libgmm-dev (or libgmm++-dev): gmm package - python-getfem : python interface In comparison to the current packaging in http://svn.debian.org/wsvn/pkg-kde/krap/ the "++" suffix has been removed so that the main lib package name is in accordance with the SONAME "libgetfem4" which doesn't contain the "++" suffix. The same convention could be considered also for the gmm header files so that all the packages uniformly doesn't contain the "++" suffix in their names. 2. superlu The upstream package includes in a separate folder code which is already available as standalone packages here: http://packages.debian.org/de/source/sid/superlu http://packages.debian.org/de/sid/libsuperlu3-dev in my packaging I build the code with the --disable-superlu configure option in order to use the installed version of superlu instead of the local copy in the upstream package. Though here I have a question: Which of the following possibilities is preferable? a) delete the superlu folder and recreate an orig.tar.gz with the .dfsg name suffix. b) let the superlu folder as is, but use the --disable-superlu configure option to ignore this local copy of superlu during the building. In this case I have to extend my debian/copyright to describe the license of superlu (which apparently is BSD but the superlu folder includes also files missing a license header, is it in accordance with dfsg? In superlu standalone debian package it has been accepted so, is it a ) 3. gmm stand alone packages Since there is a debian package for standalone gmm too: http://packages.debian.org/sid/all/libgmm++-dev and since the upstream for gmm++ and getfem++ is the same, I suppose the standalone gmm++ package could be replaced by the one contained in getfem++. At this point a decision should taken also for the name of the package (libgmm vs libgmm++, see point 1). I would be glad for any feedback. As soon as I have some suggestions on these 3 issues I will upload a sid version of my package (Optimally, with the support of the current maintainer, in a new branch in the same place where he has his work). Regards Kostas
