This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ITP] astrometry.net-0.38-1


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]