packaging Siconos
Dear Debian Science team,
I am working on an open source (Apache2 license) numerical simulation
engine for non-smooth dynamical systems which is called Siconos:
http://siconos.gforge.inria.fr
Lately we have been motivated to package it for Debian Sid, and I
think the Debian Science team is the right place to propose this. I
have been working on the package itself, but now I would like to know
more about the process for contributing to Sid. I have several
questions before I make a Debian bug and propose the package for
sponsorship.
First and foremost, our development is hosted on github, and I have
been working on a fork of our repository on a branch called
"debian/sid", following recommendations here:
https://wiki.debian.org/PackagingWithGit
Currently the package code lives at:
https://github.com/siconos/siconos-deb/tree/debian/sid
1) Now, I am wondering if it is useful/required for me to move this
repository to Alioth?
If so, I can report a problem registering an account, I have tried
twice and both times after email verification I am greeted with this
error message:
"Exiting with error
Could Not Get User"
In any case, on to more questions:
Siconos has several layers, each with their own shared library: one
wrapping "external" libraries such as numerical routines found on
various university websites, I'll come back to this; then there is a
"numerics" library which provides an interface to a series of
numerical solvers; on top of this there is the "kernel" which
provides a C++ framework for modeling non-smooth dynamical systems;
there are then some application-specific layers on top of these such
as "control" and "mechanics"; finally, there is a set of Python
modules wrapping all these libraries generated by SWIG. We also have
examples and documentation.
To represent all of this I have divided the software into several .deb
packages, libsiconos-numerics, libsiconos-kernel,
libsiconos-mechanics, etc. as well as a Python package python-siconos
to install the SWIG bindings, and siconos-mechanics-tools to install
the 3D viewer we use for visualizing results in 3D contact mechanics,
as well as some tools for manipulating the files (in HDF5 format). I
have also made some metapackages e.g. libsiconos-all-dev and just
"siconos" that install everything needed for Siconos development, and
everything at all Siconos-related, respectively.
I also made siconos-doc and siconos-examples, however to build
siconos-doc we need sphinxcontrib-bibtex which appears to be "in the
pipeline", so I will wait on that one. https://bugs.debian.org/800358
2) I would like to know what Debian Science's take on this packaging
approach is, what should I do differently if anything? I would like
to prepare the package for sponsorship.
The "libsiconos-externals.so" library is actually a collection of
"other" code that Siconos depends on but is not readily available
through apt-get. As such it doesn't really make sense to package it
as part of Siconos, so in my package I actually compile
libsiconos-externals.a as a static library and link it with
libsiconos-numerics (which is really the only part of Siconos that
uses it). For Debian, I think it would be more acceptable to package
these dependencies separately and make Siconos depend on them. I
would be willing to do this work. It is all code published under
permissive licenses, here is a list of them:
- public domain code from http://www.netlib.org, in particular
"odepack"; is there any history of this code being packaged previously
for Debian? I do not want to duplicate efforts, but would be willing
to make packages for what we use.
- numerics_bindings: this apparently has already been proposed for
Debian in 2009 but was closed, perhaps out of lack of interest, would
it be possible for it to be re-opened? https://bugs.debian.org/536270
- two of our optional dependencies do have weird license situations:
PATH has a strange license found at
http://pages.cs.wisc.edu/%7Eferris/path/LICENSE and SOL/lumod seems to
have no license at all:
http://web.stanford.edu/group/SOL/software/lumod/ ; so the question
is, should I remove these from our source release tarball using a
patch? I will perhaps approach the authors ask about their license.
- Some Fortran routines from Ernst Hairer here:
http://www.unige.ch/%7Ehairer/software.html
These explicitly have a permissive license
http://www.unige.ch/~hairer/prog/licence.txt, so I would be willing to
make a package for them.
Of course it's *easier* to just statically link all of these directly
into our package, or include them as a private shared library. So,
3) I would like to know what Debian Science thinks of the static
linking or private library approach, vs. making dedicated packages for
these collections of Fortran routines.
(Many of them could be useful for other numerical simulation software,
e.g. Evan Drumwright appears to have packaged odepack for use with his
Moby software http://www-robotics.usc.edu/%7Edrumwrig/code.html)
Thanks for any feedback you can give me. Currently I am making the
package based on our last year's release (4.0.0) but I would like to
take any packaging concerns into account "upstream" before we do a
4.1.0 release sometime this year.
regards,
Steve
Reply to: