[Stardata-common-devel] Astronomy Debian packages

[Kevin B. McCarty]

Hi folks!  Many apologies that it has taken me so long to look at these
packages.  Here are my comments.

Francisco García wrote:

> -stardata-common 0.1
> http://usuarios.lycos.es/franciscogarciac/debian/stardata-common

A number of files in the source package seem to have an executable bit
set which normally should not (e.g. debian/changelog, doc/policy,
debian/README.Debian).

Do either of you think there also should be a prerm script that
un-registers everything (mirroring the postinst script registering
everything)?  I have no opinion in either direction.

I noticed a few minor typos in doc/policy; I'll send a patch in a
separate email.  Otherwise things look fine.

> -spacechart 0.9.5-10
> http://usuarios.lycos.es/franciscogarciac/debian/spacechart-0.9/

The orig.tar.gz on your website gives a "Forbidden - you don't have
permission" error.  I did obtain it from ftp.debian.org though.

I'm a little bit concerned about statements in debian/spacechart.sh
where several statements "[ -f something ] && rm -f something" are
chained together.  If "something" doesn't exist, won't the whole chain
return non-zero?  Since the script is set -e, that will cause it to
error out.  I suggest rewriting them as if ... fi constructs:

if [ -f /usr/share/spacechart/gliese.stars ] ; then
	rm -f /usr/share/spacechart/gliese.stars
fi

(also I don't think the -f flag to rm is needed: If rm, running as root,
can't delete an existing file, then something is wrong and the script
_should_ error out.)

By the way you could shorten these paths by putting the definitions of
$GLIESE_* above the beginning of the case statement so you can use them
for both install) and remove) cases.

Aside from these nitpicks I think this looks good.  I have one other
question about the overall source package: it looks like some files
generated by flex and bison (src/rcparser_l.c, src/rcparser_y.c,
src/rcparser_y.h) are patched in the Debian diff.  Should they be?  If
they are regenerated from the .l and .y files at build time, they should
probably be deleted by "debian/rules clean" so they don't appear in the
diff.gz.

> -starplot 0.95.2-3
> http://usuarios.lycos.es/franciscogarciac/debian/starplot/

In the starplot postinst and prerm scripts, did you mean "exit 1" after
echoing "called with unknown argument" ?

In starplot.sh, same comments apply as above regarding the construction
"[ -f something ] && rm -f something" (and similar).

One other thing I suggest is that we add the files gliese.spec and
yale.spec into the starplot package, maybe to the directory
/usr/share/starplot/specfiles (for instance).  To me, it makes more
sense to have them here than in the gliese/yale packages.  This will
necessitate using "starconvert" instead of "starpkg" in the starplot.sh
script.  For backwards compatibility with older versions of starplot,
however, the gliese and yale packages must keep installing their copies
of the .spec files to the same places as before until after the release
of Etch.

> -gliese 1.1-13
> http://usuarios.lycos.es/franciscogarciac/debian/gliese-1.1/

In debian/control, line 13, s/start/star/
The second paragraph of the long description should maybe be changed to
read something like "This stellar data set may be viewed with the
Spacechart or StarPlot programs available from Debian."

In the postinst and prerm scripts, again I think you want to "exit 1"
after an unknown argument is given.

> -yale 1.0-12
> http://usuarios.lycos.es/franciscogarciac/debian/yale-1.0/

I get another "Forbidden" error trying to download the orig.tar.gz.
Retrieved it from ftp.d.o.

Same comment about the postinst/prerm scripts as for gliese.

Overall, these look almost ready for upload!  Please let me know once
you have been able to implement the comments I've made above and I will
check over the revised packages again.


Now I have a few ideas for farther in the future -- let me know what you
think.

- I noticed that the postinst and prerm scripts look very similar
between starplot and spacechart.  Maybe we could add a
dh_registerstardata script into the stardata-common package to keep
things consistent at build time.

- What would you think about having each star program Provide
<stardata>-viewer for each star data set it can handle, and having each
star data package Suggest <stardata>-viewer?  For instance, starplot
would have "Provides: gliese-viewer, yale-viewer", spacechart would have
"Provides: gliese-viewer" and gliese would have "Suggests: gliese-viewer".

- IMO the gliese and yale source packages should be re-built starting
from pristine upstream tarballs (not from the modified tarballs I
distribute at the starplot web site).

- Once my thesis is finished I hope to have time to package the
Hipparcos data.  Since it is very large, my plan is to build three
binary packages, containing a small subset of the data
"hipparcos-small", a medium-size subset "hipparcos-medium" and the full
data file "hipparcos-full".  These would all Conflict, Replace and
Provide a "hipparcos" virtual package.  They should be able to go into
main, judging by the data/COPYING file in spacechart source code, so
this will allow more packages to transition into our stardata-common
scheme of things.


By the way, have you noticed there is now a "debian-science" mailing
list debian-science at lists.debian.org ?

best regards,

-- 
Kevin B. McCarty <kmccarty at princeton.edu>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/    Princeton University
GPG: public key ID 4F83C751                 Princeton, NJ 08544