Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
content-class: urn:content-classes:message
Subject: new packages
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 1 Nov 2001 16:08:32 +1100
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Message-ID: <EA18B9FA0FE4194AA2B4CDB91F73C0EF7A47@itdomain002.itdomain.net.au>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: new packages
Thread-Index: AcFik0B3YW46r5tYT/u2klmpvCcmzQ==
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-developers AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id fA150qL25711

I'd like to add 2 new 'packages' to the mirror package hierarchy.

They don't need to appear in setup.ini, but I suspect that the package
scanner will add them automatically :p.

If they are marked as experimental will that suffice for preventing user
confusion?
(Oh, and what is the tag for experimental again?).

The files are:
latest/setup/setup.exe and
latest/setup/copyandspawn.exe

The reason to have them in the mirror hierarchy is that they can be
downloaded from mirrors, not just cygwin.com, and they should be in sync
with the version of setup.ini.

The reason for testing is that setting up a set of mirror hierarchies
doesn't really appeal :}.

As for what they do....
setup.exe will be the most recent released setup.exe, (possibly version
stamped in the name, but that can be address'd later), and copyandspawn
is a trivial little program that probably should be called moveandspawn.

copyandspawn 30 foo bar foo.exe waits for process 30 to quit, moves foo
on top of bar, and runs foo.exe. Setup can use this to step up to a
newer version without the user needing to manually download and recall
where they had setup.exe located. The only current hitch is that
setup.exe appears at the back of all the other windows, which IMO is a
bug - and related to the other reported window level bugs.

(yeah, trivial immediate benefit, but it's always bugged me). It should
also reduce cygwin.com traffic a little, as it will download from the
mirror site the user selected. 

The follow-on is that if setup.exe has a persistent cache directory to
store packages in, it can be placed into the cygwin /usr/bin directory,
and be run from anywhere with consistent results. Oh, and yes I've got a
patch in the wings for that too.

I'm not sure that this work should go into the first release of the
dependencies to the end users, but thats certainly an option...