Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3CE47E5D.4070306@ece.gatech.edu>
Date: Thu, 16 May 2002 23:51:57 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/00200205
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John Haggerty <haggerty AT bnl DOT gov>
CC: cygwin AT cygwin DOT com
Subject: Re: setup.exe 2.218.2.8/9 broken
References: <3CE46BA4 DOT B9D34815 AT bnl DOT gov>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)

John Haggerty wrote:

> 
> If you're going to work on this, could you leave a working version in
> place while you do so, and try it before posting it?  Thanks.
> 

Long story:

(1)
In order to allow HEAD testing to go forward with md5sums, there was a 
minor change to the 'stable release' of setup.exe (and to the setup.ini 
format and to the upset script that generates setup.ini) to
   a) put md5sums for each tarball into setup.ini
   b) make the current setup.exe not barf when it saw them

This was a simple change, and was uploaded with little testing or 
fanfare.  BUT, since setup.ini's format changed, it broke all older 
setup.exe's.  This forced everybody to use the most recent 'stable 
release' of setup.exe; many people had been 'hanging back' with old 
obsolete versions.  Perhaps this was impolite of us (and it wasn't 
intended as a "we're gonna force everyone to always ride the bleeding 
edge" thing) -- but it ended up having exactly that effect.

As it happened, the 'most recent stable release' of setup.exe (non-HEAD) 
was teetering on the edge of a number of bugs...and the wider (forced) 
testing made those bugs visible.

(2) bug #1: we ran out of parser stack space when all the new XFree86 
packages were added to the distribution.  This was the source of most of 
the problems over the last week.  Too many packages in setup.ini + not 
enough stack space + RHS recursion(?) == the lex setup.ini parser barfed.

(3) bug #2: minor issues with parsing "buried" setup.ini files -- that 
belong to things NOT cygwin-setup.exe-related.  This happens only when 
someone says "My local setup directory is HERE" when HERE has 
subdirectories that don't belong to cygwin-setup.  (That's bad, don't do 
that: setup's 'local directory' is his own personal playground and he 
doesn't play well with others)
   This is what happens when user-error meets bad filename parsing...and 
since the userbase of the 'most recent stable release' of setup.exe 
expanded drastically overnight, we got hit with lots of reports about 
this problem.

Normally, it is Robert and Chris's policy that unstable development of 
setup.exe happens on the HEAD branch (currently 2.A, A > 218).  Bugfixes 
for the officially released setup.exe happens on a side branch (in this 
case, 2.218.2.X).  Unfortunately, a confluence of events, plus an 
accomodation for HEAD's setup.ini format change, led to serious 
instability in the "stable release" of setup.exe for a while.

Hopefully things are better now...just think of setup-2.218.2.X as linux 
kernel 2.4.X, where X < 9...

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/