[Stardata-common-devel] Astronomy Debian packages

Thu Aug 25 07:17:57 UTC 2005

Hi Kevin,

---------------------------------------------------------
It must be that part of my email got lost. I send it again.

Yes, I have uploaded my new packages, and please, I would
like that you take a look at it.
---------------------------------------------------------

I have reviewed your new revision of policy, and I think now it
is much better than before. 
I agree with it, so it have been replaced. Just one little thing, let
me put your name in the first place in policy file, because the policy
text is mostly yours. 
This is probably a minor matter but I think this is the correct way.

Anyway I think we should keep reviewing it for possible changes.

El vie, 29-07-2005 a las 13:06 -0400, Kevin B. McCarty escribió: 
> Hi folks!  Many apologies that it has taken me so long to look at these
> packages.  Here are my comments.

No problem, lots of thanks for your work.

> 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).
> 
Yes, I didn't realice of it. I supose that was produced while moving
files from a machine to another. Solved.

> 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.
> 
Well, It could be useful but, if someone uninstall stardata-common,
stardata sets should be uninstalled too?, maybe yes.
Or, maybe someone just wants to uninstall stardata-common package and
wants to keep the stardata sets?.
How the best, and cleanest, way to remove the stardata sets (not
catalogues packages) is using register-stardata, I think that could be
nice to uninstall all the catalogues on uninstall stardata-common to
keep the system clean. 
So, if both of you agree with it, I add a prerm script.

> 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.
> 
Ups, I am sorry, I will review those files.

> 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
> 
Yes, I agree with you. It is fixed now.

> (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" ?
> 
Yes, fixed.

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

> 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.
> 
Yes, It looks that starplot spec files must be present in starplot
package.
So, I have added them to the starplot package
in /usr/share/starplot/specfiles, as you suggest.
I have changed the starplot.sh script, now it calls to starconvert
program to convert the data sets.

Gliese and Yale packages still contain the spec files for compatibility 
with older versions od starplot.
I agree with keep them until 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."
> 
Ok, I have changed the second paragraph of extended description field.
Changed the yale package extended desciption too.

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

> > -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.
> 
Solved.

> 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.
It could be useful. I'll think about it. 
> 
> - 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".
> 
Ok, I think It is a good idea. 
I add Provides field to debian/control in Starplot, Spacechart.
And Suggests field in Gliese and Yale.

> - 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).
> 
I will see this point.

> - 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.
> 
Ok, It is great.

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

Please, take a look at my new packages.
I hope your comments, and thank you again for your revision.
Best regards.

Francisco García Claramonte.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/stardata-common-devel/attachments/20050825/b445ae4d/attachment.pgp