Re: Bug#867382: ITP: vspline -- generic C++ code for uniform b-splines, remap functions
Le vendredi 04 août 2017 à 11:52 +0200, Kay F. Jahnke a écrit :
> Am 14.07.2017 um 15:40 schrieb Sébastien Villemot:
> > I am the maintainer of einspline in Debian (under the Debian Science
> > umbrella).
> >
> > I am wondering what should be done with that package. It seems
> > abandoned upstream, does not compile against upcoming GCC 7 (see
> > #853385), and I personally no longer use it.
> >
> > As someone who has a deep knowledge of various B-Spline codes, what is
> > your opinion? Should we remove it from Debian, since it is abandoned
> > upstream, or is it worth keeping it by adding our own patches? Has
> > someone created a lively fork? Would you be interested in maintaining
> > it (upstream and/or in Debian)?
> I haven't touched libeinspline in a while myself, now that I have my own
> b-spline implementation, which suits my needs much better. When I
> started out using it, I had very limited success communicating with it's
> author, and he did not acknowledge the existence of the python interface
> I wrote for it, though it was listed as to-do on libeinspline's website.
> Eventually I gave up trying to build on top of libeinspline. My
> impression was that the author has lost interest in his library and has
> moved on to do other stuff. As you say, it seems abandoned upstream. I
> have tinkered with the C code, but I haven't come up with anything worth
> publishing, and I know of no fork. I would not like to maintain it, in
> fact I'm glad to have my own code to work with now.
>
> On the other hand, when only cubic splines in up to three dimensions are
> needed to be used with C or fortran code, it provides a usable code
> base. The basics - prefiltering, and evaluation - work well enough, but
> there are also some ideas which were begun and seem not to have been
> properly finished. It could do with a cleanup job, if it were to be
> continued. I was surprised to find it as a debian package in the current
> state, there are too many loose ends for my taste. What probably sets it
> apart is the clear focus on b-splines, which fits the unix philosphy of
> providing a specific tool for a specific task, and currently there seems
> to be no other package available specifically for uniform b-splines.
>
> With this unix focus, I have written vspline. The code, being generic
> C++, covers more ground, but omits a few specifics of libeinspline which
> I feel don't really belong into a b-spline package. But my code is new
> and complex, and the API will probably go through a few changes before
> stabilizing properly. And so far I haven't managed to elicit much
> interest for it, let alone find a sponsor. I did intend to ask you,
> Sébastien, if you might not be interested in considering sponsoring my
> package, since you are libeinspline's maintainer and therefore might
> have a good idea about the topic.
>
> I am of course biased, but I feel vspline has the potential to fill the
> niche for a uniform b-spline library in debian. I'd rather invest
> development time there than trying to patch up libeinspline. If anyone
> needs it specifically they should come forward and do the task - from
> briefly looking at the gcc7 compilation errors (#853385) it looks to me
> that the affected code is merely performance testing code (sorry, I
> don't have gcc7 here). The minor changes to libeinspline when debianized
> (as far as I know just one bug fix) and the packaging effort can
> probably be written off without too much regret, and anyone needing
> libeinspline can still access the code from upstream, so I'd say that
> removing it from debian would not be a great loss.
Thanks for your feedback.
The FTBFS of einspline is now of severity serious, since GCC 7 has
become the default in unstable. The fix is not obvious to me, so I have
forwarded it upstream. Let's see if they reply, and if they do not, I
will request the removal of the package from Debian.
Concerning vspline, I am of course willing to help you get it into
Debian. However, you should be aware that you are expected to do proper
ABI tracking of the library once it is packaged (see [1]; see also [2]
if you intend to create the shared library with libtool, which I would
recommend). So, if your library is still under intense development, it
may be wiser to wait a little bit before pushing it to Debian and let
the dust settle, otherwise you may end up changing the SOVERSION and
going through the NEW queue for every new upstream release.
Cheers,
[1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-updates
[2] https://www.gnu.org/software/libtool/manual/html_node/Versioning.html#Versioning
--
⢀⣴⠾⠻⢶⣦ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name
⠈⠳⣄ http://www.debian.org
Reply to: