Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: setup.exe 2.218.2.8/9 broken
Date: Fri, 17 May 2002 14:06:36 -0400
Message-ID: <BADF3C947A1BD54FBA75C70C241B0B9E10AA18@ex02.idirect.net>
From: "Harig, Mark A." <maharig AT idirect DOT net>
To: <cygwin AT cygwin DOT com>
Content-Transfer-Encoding: 8bit


> -----Original Message-----
> From: Charles Wilson [mailto:cwilson AT ece DOT gatech DOT edu]
> Sent: Friday, May 17, 2002 1:00 PM
> To: Harig, Mark A.
> Cc: cygwin AT cygwin DOT com
> Subject: Re: setup.exe 2.218.2.8/9 broken
> 
> 
> Harig, Mark A. wrote:
> >>-----Original Message-----
> >>From: Charles Wilson [mailto:cwilson AT ece DOT gatech DOT edu]
> >>Sent: Thursday, May 16, 2002 11:52 PM
> >>To: John Haggerty
> >>Cc: cygwin AT cygwin DOT com
> >>Subject: Re: setup.exe 2.218.2.8/9 broken
> >>
> > 
> > (text deleted)
> > 
> >>(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)
> > 
> > 
> > I hope that this isn't going to be the solution to the problem of
> > setup.exe finding non-setup.exe setup.ini files.  Although 
> I don't think
> > that I will make this mistake again, I expect that it will happen to
> > future users who are not reading this list today.
> 
> Perhaps some explanatory text on the panel where setup asks 
> for "local 
> directory" would be nice.  Something like "This is the cygwin setup 
> program's private cache.  Do not choose a directory with pre-existing 
> contents, unless those contents are the result of an earlier 
> run of this 
> setup program".  Care to provide a patch?
> 
> But no, it's not "the solution".  Chris has already added 
> some code that 
> assists setup in parsing only "proper" setup.ini files and skipping 
> non-setup.exe-related ones.
> 

It's the "do not choose" portion of this solution that I hope setup.exe
would avoid because it isn't paying attention to Murphy's Law.  The way
setup.exe runs now there are (at least) two possible sources of errors:

  1) setup.exe's setup.ini has become corrupted.  This is well handled
by setup.exe with its display of parsing errors.

  2) The user may have selected a Local Package Directory that contains
non-setup.exe setup.ini files.  The message that is reported for this
user error (that is, 'user selected a Local Package Directory that has
non-setup.exe package files in it') is, unfortunately, the same message
as that used to report problem 1, above.

     This can be doubly confusing because a user can run setup.exe
successfully for a long time, and then find that it stops working due to
mysterious parsing errors because s/he has installed some other package
("I'm keeping all of my installations in a single, separate directory
tree").

     So, even if we add the text you suggested telling the user about
the rules for 'Local Package Directory', setup.exe should report the
error better (i.e., not reuse the error processing method of different
kind of error) when the user doesn't follow the rules.

-mark

--
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/