On Tue, Feb 7, 2012 at 8:56 AM, Tim Jenness <[log in to unmask]> wrote:
> On Tue, Feb 7, 2012 at 1:27 AM, Ole Streicher
> <[log in to unmask]> wrote:
>> I am currently (re-)packaging saods9 for Debian (and Ubuntu). ds9 uses slalib directly as well as a part of the astlib.
>> Both ds9 and astlib, however, use a obfuscated C version of the slalib which does not meet the Debian guidelines; see
>> So, I plan to use the Fortran version that is provided by starlink (see <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659003>). For this, I have some questions:
> There is a lot of history associated with SLA and there is a reason
> that the routines inside AST are actually called PAL. Pat Wallace has
> asked that the only versions of the code that can be called SLALIB are
> the original Fortran code and his proprietary C implementation. The C
> version is the one that everyone would like to use but we can't so we
> struggle on with the Fortran implementation. The problem though is
> that AST now supports threads and can no longer use the Fortran code
> since Fortran is not thread-safe and mutexes in the fortran SLA layer
> would kill performance.
> To get around this Pat graciously allowed AST to use some of the C
> library so long as it was (1) the obfuscated version and (2) rebranded
> as PAL. So I think at present all the routines are called PAL so we
> can't simply link against SLA.
> I think that if we started rewriting the SLA Fortran library in C Pat
> would probably prefer that we rebranded it as PAL (as was done in the
> Java rewrite). Pat wants SLA to be something that he can stand behind
> and would not like people to start complaining about a broken SLA if
> the breakage was caused by a bug in the C rewrite.
> I'm not sure what the situation is with DS9 since I assume Pat gave
> permission for DS9 to have a subset of obfuscated SLA as a special
> case but that was in the days when downstream licensing issues were
> discussed less.
One alternative is to switch all C use of SLA to the SOFA library
which looks very compatible but I'm not sure if the SOFA Software
Licence is compliant with Debian
One thing I recall is that I was not allowed to write a perl wrapper
around the SOFA C library on the basis that:
1. I was not allowed to call any of the perl functions by their C
name unless I retained the exact same C interface in the perl layer
and even then it was questionable whether I was going to be allowed to
2. I was not allowed to include the sofa source code in my Perl
distribution (people would have to install SOFA themselves first)
So it's highly unlikely that the SOFA C code will want to be packaged
up in debian. There seems to be a feeling that it should only be
downloaded by an individual user in source form from the SOFA website
to ensure the integrity of the SOFA brand. I can't imagine people
wanting to patch the source code and ship it as a new and improved
I really wanted SOFA to allow redistribution and the addition of new
language interfaces if the underlying code was not modified.
Starlink User Support list
For list configuration, including subscribing to and unsubscribing from the list, see