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 <[EMAIL PROTECTED]> (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
