This is the mail archive of the
mailing list for the Cygwin project.
Re: [ITP] astrometry.net-0.38-1
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: Mailing List: CygWin-Apps <cygwin-apps at cygwin dot com>
- Date: Mon, 07 Nov 2011 09:46:21 -0500
- Subject: Re: [ITP] astrometry.net-0.38-1
- References: <CAH7za-Bv7D84wjExfGe_Y7oYGSwq=Q61OGjq7J3wP56i_OcwBA@mail.gmail.com> <email@example.com> <CAH7za-Bw8ppYPwQkvxo03Q4dmi0vPo3qEMJJz+2EwaO25n8firstname.lastname@example.org> <4E8F0AA2.email@example.com> <CAH7za-BpsVVDPoLHVHC+o40pFjPEATMv_sL=tu7zPAd1kB7uGg@mail.gmail.com> <4EB3865A.firstname.lastname@example.org> <4EB45567.email@example.com> <CAH7za-CJJOxxWsm587OaZOvynQza029bFi59VOrKOLin-_-2Pw@mail.gmail.com>
- Reply-to: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
On 11/7/2011 8:18 AM, Jussi Kantola wrote:
> On Fri, Nov 4, 2011 at 11:13 PM, Charles Wilson wrote:
>> You should probably do that, to ensure that the build procedure works on
>> your machine. Also, to test the resuts; I have no idea how to use this
> It builds fine, and the resulting installation works fine when I put
> some sky catalogs in /usr/share/astrometry/data/.
Good news. Please post *your* rebuilt packages somewhere, so they can
> The question
> becomes, would it be better to create a separate package
> (astrometry.net-data-tycho or such) for the (example/test) catalogs,
> than to have them in the binary/source packages? Theoretically, and I
> suppose in eventual actuality as well, there could be many different
> sets of catalogs, so separate packaging sounds like the way to go ...
Definitely separate. However, it may be best not to create any catalog
packages at all, and instead provide helper scripts (in
/usr/lib/astrometry/scripts/ ?) to d/l and install the individual
catalogs. The reason for this suggestion is twofold.
First, if you create a cygwin package containing the data from catalog
"foo", then cygwin will be *redistributing* that data. However, many
scientific databases of this sort, while free (gratis) to use, prohibit
redistribution -- everybody is required to get them directly from the
source. So, for this sort of catalog, a helper script to enable the
end-user to do THAT is the only solution.
Second, these catalogs are HUGE. 70GB? 25GB? That's 10 to 30 times the
size of the entire cygwin distribution, source and all -- for one
catalog. Our mirrors probably won't accept that.
>> Provided you can rebuild this package on your machine, AND that it actually
>> works, consider it GTG.
> With the notice/question above, it worked like a charm -- and I thank
> you dearly!
I have to admit, it was pretty painful. The upstream astrometry guys
really should work on making their project more cross-platform- and
distro-packaging- friendly. E.g. use the autotools including autoconf,
automake, and libtool throughout, and treat all of the "helper"
libraries -- gsl-an, libkd, liban*, etc -- as libtool "convenience
libraries", link all the utils against the top-level backend lib, ...
"Oh, but we'd lose all the make-it-really-fast fine-tuned CFLAGS
settings in our hand-rolled makefiles" -- fine, create a FastMakefile
that deduces the platform, and invokes (top-level) configure with the
appropriate CFLAGS, CPPFLAGS, and LDFLAGS, and tell users to do
make -f FastMakefile && make
..."Premature optimization is the root of all evil." -- Donald Knuth.
E.g. make it work, THEN make it work fast.
But that's not your problem...nor mine. :-)
Go ahead and post your rebuilt packages, and I'll upload them. Postpone
the star catalog pkgs and/or "helper scripts" for the -3 release (*)
(*) howto: drop the scripts in the CYGWIN-PATCHES directory, and add
lines like the following to the end of the src_install() function in the
Since the scripts would probably use wget or curl to d/l the catalog(s),
you'd want to update the requires: line in your setup.hint.