Bug#216874: Situation of astronomical packages, ITA offer and proposed RFC
On Sat, Apr 17, 2004 at 03:05:58PM -0400, Kevin B. McCarty wrote:
> Hi Javi and others,
Hi there.
> 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.
There has been one volunteer (it's just not in the BTS info):
Francisco García <franciscomanuel.garcia@hispalinux.es>
(in CC)
I have not yet been able to review his packages (up at
http://usuarios.lycos.es/franciscogarciac/debian/). But I would appreciate
it you contacted him and considered co-maintaining those packages.
> 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.
Great.
>
> 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.
Sounds ok.
>
> 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.)
Sounds good.
>
> 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.)
Sounds good.
>
> 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.
Correct.
>
> 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.
Notice that if you removed the startdata stuff but installed a package that
was using c) then you would end up with a program that does not work. I
think that c) should be ruled out.
>
> 5) Each program that requires some preprocessing of a data file before
> using it (I think starplot is the only such program) should:
Some other programs use modified versions of the star data catalogues but
do not provide preprocessors to regenerate the data IIRC.
> 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.
Why remove the stardata if you have already preprocessed it? I don't think
that's really necessary. However, there is a reason for doing it in the
stardata catalogues instead of doing it in the programs themselves: it's
necessary in order to be able to install the stardata catalogue after the
program has been installed (and thus, avoid Pre-Depends:)
> 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?)
I'm not sure if /usr/share is better than /var/lib.
> 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.
Agreed. Also note that someone needs to write preprocessors for those
packages that might use catalogues but not in the canonical form (i.e.
xephem, see #225002, openuniverse and, maybe, stars)
> 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.
I think it's also important to make a list of the astroprogram packages
available in Debian and what data they use. As far as I know:
- kstars: Hipparcos
- stars: uses quite a number of catalogues, including Yale's. There
is not mentioning as to their copyright (so all should be assumed not to be
DFSG-free) (see bug #244551)
- xephem: uses a derived version of Yale's (see bug #225002)
- starplot: can use Gliese or Yale (regenerates data on install)
- spacechart: Hipparcos, can use Gliese or Yale if available
- openuniverse: a subset of stars based on Yale's (should be bugged like
xephem and stars)
- celestia: Hipparcos and Henry Draper catalog (see bug 174456)
- gstar: Yale, SAO (should be bugged like xephem and stars)
So out of 8 packages: 4 include Yale, and 3 include the Hipparcos data set,
only one (starplot) does not provide any data itself. Notice that only two
(starplot/spacechar) can use stardata catalogues installed similarly to how
the 'yale' and 'gliese' packages provide them, even though these packages
have been available for over three years now!
Regards
Javier
Reply to: