Version number? Mind me packaging for Debian?

[smoe]

Dear Bill,

I had a look at compiling FInd_Orb for Linux and found Lunar over it. Many thanks for your work! The context is that I was about to prepare a package for the Debian Linux distribution. There is the Debian-Astro initiative and that yet lacks orbit determination. Would you mind your tools to be redistributed as a part of the Debian Linux distribution? Over time, this would also see them migrate to Ubuntu and Mint.

What I would kind of need is a version number that I can give to the package so the package can non-ambiguously be updated. This can be the date that I checked out your repository but if there are any preferences on your side, please tell me.

I had toyed with the thought to give the packages of yours a common prefix since there is a lunar library already (for chinese characters). This could be gray-lunar and for consistency then eventually also gray-find-orb. But pluto-lunar would also do - any preferences? The default with Debian would be to use an institute name.

Many thanks

Steffen

[smoe]

I have decided in favor of the "pluto-"-prefix and locally have a working package. In that process I found that the file watdefs.h is redundant with your jpl_eph package, which may or may not be intentional. I have put jpl_eph as a build dependency for the "integrat" binary already, so there would not be any additional overhead if that file was only distributed once.

The packaging will go to https://salsa.debian.org/debian-astro-team/pluto-lunar. Uploads may first go to experimental until I got around to addd shared libraries - it seems like a bit of an overhead, admittedly.

[Bill-Gray]

Dear Steffen,

Thank you. Getting this packaged has been on my "to do" list for a while, but... I've never packaged anything, for Debian or anything else, so I've just gone with distributing source code. (You should keep this in mind; there are probably things to be done to make the code "packageable" that would be obvious to somebody who had done it before. Don't assume they'll be obvious to me!)

As you've found, the code has a twisty maze of dependencies, all alike. If you just do a plain make for this project, there are no dependencies. Run make integrat, and it depends (as you found) on jpl_eph. Similarly, you can run make for jpl_eph and not encounter dependencies... but if you try to make sub_eph, that utility is dependent upon lunar.

find_orb is dependent upon both of these libraries, and on the sat_code library, which provides routines for handling artificial earth-orbiting satellites. (sat_code, by the way, includes norad.h'. I'm not familiar with the McNeight/GLsat project.) Severalsat_codeutilities rely on thelunar` library.

Thanks for tackling this problem. Quite aside from the fact that it'd be good to get this suitably packaged, it'll probably result in my learning enough about the process to perhaps be able to do something similar for a few other projects of mine.

[smoe]

Dear Bill,

Thank you for your very kind reply. The packages are now uploaded to the Debian distribution where they are manually checked for redistributability and that I have not messed up to much. Once those technicalities have been completed I'll drop a note. It may be worthwhile to point your users to those packages, especially for those who aim at using them in a docker environment or in one of the many compute cloud services.

That "salsa.debian.org" is a gitlab site featuring your packages at

https://salsa.debian.org/debian-astro-team/pluto-jpl-eph https://salsa.debian.org/debian-astro-team/pluto-lunar https://salsa.debian.org/debian-astro-team/pluto-sat-code https://salsa.debian.org/debian-astro-team/pluto-find-orb

where you have the opportunity to improve descriptions of the packages or change whatever else nags you about the packaging that is easier to fix than to write an email about. We can eventually discuss (as in "you tell me") what testing routines should be called during the build and which of your tools would deserve a man page and should go to /usr/bin instead of being hidden in /usr/lib/pluto/. The man pages should then of course be contributed to your repository. There is a neat "help2man" tool that helps automating the process for those tools that react nicely to a "-h" or "--help" command line argument.

As a bit of a sidenote, I was particularly happy to have read through precover.txt. You certainly have a plethora of contacts into the field and most likely do not need my help with this. But tell me when I am wrong and you find something I can do to help.

Best,

Steffen