>>>>> George N White <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
