[ITP] astrometry.net-0.38-1

Charles Wilson cygwin@cwilson.fastmail.fm
Wed Nov 9 23:24:00 GMT 2011


On 11/9/2011 5:00 AM, Jussi Kantola wrote:
> AstroTortilla is fine with a custom repo.  All we ever wanted was to
> be able to install astrometry.net with Cygwin's setup.exe

OK.

> How many
> would we need for it to be considered significant enough?

No idea.

> Is this document still valid?
> http://sourceware.org/cygwin-apps/package-server.html

Seems accurate -- but it's missing information about gpg security.  I 
think you want "Creating a custom Cygwin package server" -- you probably 
don't want to create or host a full mirror.

> Anything else I need to know?

Here's what I do, locally:

<top>/setup.exe
<top>/genini
<top>/release/foo/foo-1.2.3-1.tar.bz2
<top>/release/foo/foo-1.2.3-1-src.tar.bz2
<top>/release/foo/setup.hint

$ cd cygwin
$ ./genini --recursive release > setup.ini
$ bzip2 -c < setup.ini > setup.bz2

Then, upload setup.ini, setup.bz2, the new tarballs and setup.hint to 
your website, replicating the directory structure (from <top>/ on down).

Now, your users will have to invoke setup.exe with the -X, because 
otherwise setup.exe will expect the setup.ini/bz2 files to be signed. 
However, turning the security measures off is a problem, because then 
your users have no protection against corrupted files on the *main* 
mirrors, either.

So, ideally, you would ALSO sign *your* setup.ini/setup.bz2 files. See 
http://www.cygwin.com/ml/cygwin-announce/2008-08/msg00001.html

Now, this still requires your end users to take an explicit action (see 
item (3i),(3ii),(3iii) in the referenced announcement.)  You could 
enable them to do (3i) or (3iii) via a batch file that you 
distribute...or...

See the cygwin-ports instructions for their users, here:
http://sourceware.org/cygwinports/

In that case, the use of 'cygstart' implies that cygwinports would be 
*added* to an existing cygwin installation; hence a bare-windows 
installation would require two separate setup.exe runs (*). This is 
actually a /good/ thing, because it means there's no confusion between 
"the standard cygwin installation on my box" and "the cygwinports cygwin 
installation on my box" -- your end users would just have one, to which 
they've added the "extra" stuff.

(*) future "update" runs of setup would handle both the 'standard' 
packages and the addons simultaneously.

> Thanks once again for your time and effort!  I'm sorry the lessons you
> gave me will go down the drain if I won't become a package manager ...
> ;-)

You're still managing a package...it just wouldn't be hosted as an 
intrinsic part of the cygwin distribution itself.

--
Chuck



More information about the Cygwin-apps mailing list