Re: SeaDAS <- SDP Toolkit <- HDF-EOS, HDF-EOS 5
>>>>> George N White <gnwiii@gmail.com> writes:
>> I'm interested in packaging SeaDAS [1] as a Debian package, and
>> since it relies on SDP Toolkit and the HDF-EOS libraries [2], I'm
>> interested in packaging these as well.
>> I believe I've a decent experience in building both SDP Toolkit
>> and HDF-EOS and the only issue left unresolved is their legal
>> status.
[...]
>> I'm therefore asking, whether there're any interest in having such
>> a specialized software packages in Debian, and could anyone review
>> and sponsor these packages for me (I'm not a DD) once they'll be
>> ready?
>> [1] http://oceancolor.gsfc.nasa.gov/seadas/
>> [2] http://newsroom.gsfc.nasa.gov/sdptoolkit/toolkit.html
> SeaDAS is a very specialized package, but a decent installer would be
> a big help -- I encounter many potential users who gave up due to the
> difficulties they had installing SeaDAS (often because they didn't
> know how to install missing libraries or had old versions).
I believe that I'd be able to address the library issues as
well. In particular, I've autoconfiscated both the HDF-EOS
libraries and SDP Toolkit, in order to ease the installation.
I had to build these libraries yesterday, and it took me /8
minutes/ to do so (on a decent hardware.)
It may be noted that the SeaDAS distributions provide the
versions of at least some of the libraries used. However:
* some of these libraries (GSL?) may be out of date;
* for some libraries there's no source included in the
distribution (HDF-EOS, HDF-EOS 5 and SDP Toolkit are the
notable examples);
* the `cfortran.h' file comes without the ``GNU GPL'' notice (as
an alternative to the licensing terms contained within),
rendering it non-free; the `cfortran' Debian package should be
used instead.
> Lack of a good installer also means many people end up trying to use
> very old versions due to concerns that updating may be too difficult.
Indeed.
It may be of some help to provide shared libraries instead of
static ones. Needless to say that the Autotools-based build
systems produce them with ease.
> SeaDAS is built using IDL and Intel Fortran, so few users will be
> able to build it from sources. This puts it outside the usual debian
> model -- more like the Java packages. Do you plan to include the IDL
> runtime version NASA provides?
I should have been more clear. My intent is to provide the
/part/ of SeaDAS suitable for Debian `main'.
Furthermore, I haven't yet familiarized myself with SeaDAS as of
yet. I have some experience with IMAPP (which is one of its
ancestors), as well as with the some of the PGEs (which are the
other), however.
IIUC, the IDL code serves as the wrapper around the IMAPP/PGE
pieces (is it a GUI to start the processing?) Personally, I
don't need such functionality, and it would be difficult for me
to provide it.
The parts of SeaDAS relying on IDL are probably worth a separate
Debian package in `contrib'.
> Are you going to rearrange the package according to debian rules or
> keep the NASA structure?
What do you mean by ``structure''?
As of the source package, I'm going to:
* remove all the compiled code (e. g., *.a);
* remove all the extra libraries (since it's the APT work to
provide them);
* remove all the IDL-depending (and otherwise useless in Debian
`main') code;
* replace the build system accompanying the package with an
Autotools-based one.
As of the binary package, I'm going to follow FHS.
> Keeping up with all the updates will require a significant long term
> commitment. Many people may be reluctant to try debian packaging
> unless it is consistent with NASA updates so they aren't dependent on
> your ability to keep up.
It seems to me that NASA isn't particularly eager in making
releases. E. g., the last verion of SDP Toolkit [1] was
apparently released in 2005.
Since I'd probably be tied to these packages for at least of the
next two years, I'd probably be able to provide updates in a
timely fashion. Hopefully, I'd pave the way for the future folk
to join by then.
> It would be very useful if you could just wrap the NASA binaries in a
> package that would handle dependencies, but still allow updating via
> NASA's scripts so people who need updates don't have to wait for new
> packages to be generated
Indeed, it may be possible. However, I don't feel it as
appropriate for me.
My point is not only in providing an easy access to SeaDAS to
the Debian users, but to make the package as much transparent as
possible to those who'll actually read (and modify) the source.
> (not to mention the savings in download volume, although it is hard
> to see how people can do useful things with SeaDAS if they don't have
> good network connections!).
Well, rather surprisingly, there're folks having good X-band
connections (while lacking good network connections :-).
[1] http://newsroom.gsfc.nasa.gov/sdptoolkit/mail_tk5213.txt
Reply to: