Re: packaging Siconos
Hi Stephen,
On Wed, Jan 04, 2017 at 11:10:34AM -0300, Stephen Sinclair wrote:
> 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.
Yes it is. Thanks for your intend to package Siconos for Debian.
> 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?
Yes, please do so since it has lots of advantages. One of these
would be for instance that we could add Siconos to the task "Numerical
computation" even before a final upload when residing only in Debian
Science Git [1].
> 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"
Hmmm, I'd naively say please try later again. If this does not help
you might need to contact alioth admins.
> 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.
Sounds very sensible.
> 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
Not sure about this specific package but in several cases just waiting
is not enough. Either there would be a chance to go without this
package or helping with the package sounds more promising.
> 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.
You might like to have a look at "Sponsering of Blends"[2].
> 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:
Yes, please create separate packages.
> - 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.
Not that I'm aware of. I only know that lapack is packaged.
> - 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
Either reopen or create a new ITP. Both is fine.
> - 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?
Since no license is per definition non-free you need to remove it in any
case. You might like to contact the authors of both projects to choose
a free license. I've done this with varying success in the Debian Med
team[3]. I think when writing to the authors a good start of your
e-mail would be:
I'm writing you on behalf of the Debian Science team which is
a group of maintainers inside Debian with the objective to
package free software with relevance to scientific research for
official Debian.
> 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.
To say it very shortly: Static libraries are sucking. Feel free
to ask for a longer explanation.
> (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.
Hope this helps
Andreas.
[1] https://blends.debian.org/science/tasks/numericalcomputation#pkgvcs-debs
[2] https://wiki.debian.org/DebianPureBlends/SoB
[3] https://wiki.debian.org/DebianMed/SoftwareLiberation
--
http://fam-tille.de
Reply to: