From: Alan W. I. <Ala...@gm...> - 2021-07-04 08:30:14
|
On 2021-07-02 10:38+0200 Rafael Laboissière wrote: > Dear PLplot developers, > > I am hereby forwarding a bug report filed against the Debian plplot package > regarding the use of a deprecated Qhull library [1]. Conversion of the code > to the reentrant version of Qhull needs more changes than merely linking > against libqhull_r.so instead of libqhull.so and including > libqull_r/qhull_ra.h instead of libqull/qhull_a.h [2], and should be done by > the upstream authors. Hi Rafael: Since this email is primarily directed to the upstream Plplot development list, I have generalized this discussion of how upstream PLplot development should respond to Debian Bug#990397 to the new subject line which is "What are the development priorities for the csironn library?". I would value your input into that general discussion since you are a former PLplot developer who at that time had a lot of interest in that library and its dependence on libqhull. You likely know all this stuff already, but to set up this discussion for the benefit of the others here, this is a quick review why the plgriddata routine and therefore PLplot depends on our csironn library, and that library in turn depends on the libqhull library. The lib/nn/README file documents that question from the historical (2003!) viewpoint. To add to that from my own current perspective, the fundamental issue appears to be that Pavel Sakov's free nn-c library throughout its history including [it's latest version](https://github.com/sakov/nn-c) has depended on [the triangle library](http://www.cs.cmu.edu/~quake/triangle.html) whose licensing terms are as follows: "Please note that although Triangle is freely available, it is copyrighted by the author and may not be sold or included in commercial products without a license." You (and other Debian developers) know a lot more about licensing legalities than I do so please let me know whether this license means in Debian packaging terms Triangle is non-free as asserted in lib/nn/README and therefore nn-c is "contrib" rather than "free" in Debian packaging terms. Anyhow, as a result of that perceived (and likely real, but that needs confirmation) licensing issue Joao stripped the version of the nn-c library available in 2003 to just what was needed by plgriddata, and replaced all calls to triangle library routines in that stripped version with the equivalent libqhull calls. Anyhow it is that stripped and triangle-replaced ancient version of nn-c that we call csironn and that we have been maintaining (in a small way since 2003) as a free (as opposed to contrib if the above licensing issue is confirmed) fork of nn-c. To help motivate further discussion of the subject-line topic would you please briefly comment on the *potential* importance of the csironn library in the free software world? My guess is you will find in practice it is not important (at least at present) because nobody knows about this PLplot gem, e.g., you will likely discover that no other Debian package depends on our csironn library. However, do you agree with me that situation is a real shame since the issue of interpolating from non-gridded sample points to gridded sample points is an important and fairly common issue that is nicely addressed by our csironn library? I would also appreciate your responses to the following comments and questions concerning the new subject line topic: * The original Debian Bug#990397 that started me thinking about this general topic states "your package builds and links against the non-reentrant version of Qhull, which has been deprecated by Qhull upstream and is likely to disappear soon." However, I quarrel with that "likely to disappear soon" phrase since on that subject the qhull developers say the following (from <http://www.qhull.org/html/qh-code.htm#reentrant>): "New code should be written with libqhull_r. Existing users of libqhull should consider converting to libqhull_r. Although *libqhull will be supported indefinitely* [emphasis mine], improvements may not be implemented." It is up to you, of course, but my feeling is you would be entirely justified in closing this bug report because of the "supported indefinitely" phrase above which completely contradicts the premise of the bug report! That said, from this language from the qhull developers I do agree use of libqhull is (very lightly) deprecated. Therefore "it would be nice" for libcsironn to change its dependence on libqhull to a dependence on libqhull_r (as suggested by the libqhull developers and you) since rentrancy although not the same as thread-safe often is a step toward thread safety which is an extremely desirable library characteristic. It does appear (from comments later in the above URL) this change would be straightforward so this should be a nice simple development topic for someone to implement. * It "would be nice" to update our fork to the latest version of nn-c. The reason I suggest this as a worthwhile goal is I assume that Pavel's fairly constant development of nn-c since 2003 has found and fixed more bugs in the nn-c code than we have found and fixed in our fork of that code. As a short-cut to make this development topic easier, our fork could continue to ignore everything in nn-c that is not relevant to the problem of interpolating from non-gridded sample points to gridded sample points, but see the next item below. I haven't looked at what would be required by this development topic, but my guess is it could be implemented by simply replacing the csironn routines with the corresponding nn-c routines while keeping just the part of of the csironn routines that set up and call the libqhull routines and/or fix bugs in the nn-c version of these routines that are already in csironn and which have not already been fixed by Pavel. So it might all end up as a glorious git conflict resolution. :-) * The above "would be nice" development topic should be done first, but in addition it "would be nice" to not strip nn-c at all. My guess is what was stripped was pretty minor stuff since the csironn ability to interpolate from non-gridded to gridded sample points captures all the essential functionality of nn-c. But regardless of that question, the result should be that csironn should have all the functionality of modern nn-c (i.e., it passes all nn-c tests) with the only changes being conversion of *all* triangle library calls to the equivalent libqhull calls. I hasten to add I don't want to discuss this "vapour ware" with Pavel until it turns into "real ware". However, if we accomplish that goal (i.e., if the updated csironn library passes all nn-c testing) I bet Pavel (who is a really approachable guy) would be willing to adopt our changes right into nn-c (likely as an option), and that would clear the way for that useful library to be packaged by Debian as "free" rather than "contrib" and would also allow us to abandon our fork (since it would have been merged back into mainstream nn-c development) which I think would be a highly desired outcome. I have stated on this list before (but you may have missed that), I work most efficiently on just one development topic at a time. And my current primary development topic is getting the next release of FreeEOS out the door and my two topics following that are (i) getting the next libLASi release out the door using recent PLplot to comprehensively test it, and (ii) getting the PLplot release out the door. In sum, because of these other development commitments I don't plan for now to contribute much toward any of the above three "would be nice" development topics for libcsironn other than discussing them. But if you or anyone else here that was interested in libcsironn were inspired by this discussion to create a patch to implement any of those topics (or any other libcsironn development topic that interested you), I would be happy to comprehensively test that patch in a timely manner and (assuming that was a success) push that commit to make sure your work gets into the next release of PLplot. Best wishes, Alan __________________________ Alan W. Irwin Research affiliation with the Department of Physics and Astronomy, University of Victoria, Victoria, BC, Canada. Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |