Bug#216878: Situation of astronomical packages, ITA offer and proposed RFC
Hi Javi and others,
As no one else has volunteered, I'd be interested in adopting starplot
and spacechart. I would very much like to help disentangle the mess of
redundant data and licensing problems with the astronomy-related
packages in Debian. Full disclosure: I am the upstream author for
starplot; hope that isn't considered a conflict of interest. I plan to
start the NM process after having my GPG key signed next weekend, so I
will need a sponsor to upload packages for now.
Aaron and Gabriel: what is the status of your ITA for the gliese and
yale packages? If you are still interested in adopting them, great; if
not, I have no problem taking those on as well. I would also be
interested in packaging the Hipparcos catalogue, since it seems to be
DFSG-free (public domain) from the discussions in bugs # 198495, 174456,
198499.
Here are my latest thoughts on the matter of packaging, sort of a
mini-RFC. Let me know what you think:
0) I suggest that each star data package be named stardata-<name>, e.g.
stardata-gliese, to make it easy for users to find them. (This need
only apply to the binary Debian package name, not the source package.)
If so, please read <name> for <data-package> in all the following
points. And they should probably all go in the "science" or
"{contrib,non-free}/science" sections, as well as all the astronomy
programs.
1) Each star data package should put all of the upstream materials in
/usr/share/stardata/<data-package>/ (for data and descriptions of data
format) or /usr/share/doc/<data-package>/ (for readmes, copyrights, etc.)
2) The actual ASCII data file should be named
/usr/share/stardata/<data-package>/catalog.dat (with a symlink, if
desired). If there are more than one data file, either call them
catalog1.dat, catalog2.dat, ... or else merge them. If there are more
than nine data files, call them catalog01.data, ..., catalog10.dat, ...
so that they are collated in the correct order. Similarly
catalog001.dat for more than 99 files, etc. (I am willing to be
persuaded that the numbering should start at 0 instead of 1.)
3) Each program that can use a star data file should Depends, Recommends
or Suggests the appropriate data package. If the program will fail when
the data file is not found, of course it must use the Depends
relationship. If the data package is in non-free and the program is in
main, the program must (per Policy) only use Suggests. Therefore any
program that requires a non-free data file to run must itself be in
contrib or non-free.
4) Each program that can use the data file directly (celestia,
spacechart, ...) should either
a) be patched to look for the data file(s) in the place noted above;
b) be packaged with symlinks to the data file(s), but then it must
Depend on the packages for those data file(s) in order to avoid
broken symlinks; or else
c) generate symlinks at install time, but then the program is subject
to the conditions (5a) and (5b) below in order to avoid broken
symlinks.
5) Each program that requires some preprocessing of a data file before
using it (I think starplot is the only such program) should:
a) include a packaged binary or script to do the preprocessing
b) rerun the preprocessing whenever the program or any of the data
files it can use are installed or removed. This means that the
maintainer of the program will need to ask the maintainer of the
data files to include preprocessing hooks in their postinst/prerm
scripts. A preprocessed data file should be deleted when the
corresponding star data package is uninstalled. ALL preprocessed
data files for that program should be removed when the program is
uninstalled. This is similar to how all the mozilla-related
packages call "update-mozilla-chrome" on postinst or prerm.
c) obviously the preprocessed data files may be placed wherever the
maintainer of the program thinks is best, but for consistency, I
suggest /usr/share/<program-package>/, with the file being named
<data-package>.<ext>, where <ext> is a program-dependent suffix.
Thus, "/usr/share/starplot/gliese.stars". (Maybe /var/lib/ is
preferable to /usr/share/, though?)
6) Transition: I think the easiest way to transition to this new
standard would be to upload compliant data packages first, followed by
the new program packages. This will mean a bit more redundancy in the
short term but I don't think that can be helped.
If you like this mini-RFC, or want to propose changes, let me know.
After it's stabilized, I'll send it to debian-devel for the
consideration of the other astro program maintainers.
best regards,
--
Kevin B. McCarty <kmccarty@princeton.edu> Physics Department
WWW: http://www.princeton.edu/~kmccarty/ Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
Reply to: