From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8983 invoked by alias); 17 May 2002 19:45:16 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 8966 invoked from network); 17 May 2002 19:45:13 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 17 May 2002 19:45:13 -0000 Received: from redhat.com (vpn50-7.rdu.redhat.com [172.16.50.7]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id g4HJjBu13510 for ; Fri, 17 May 2002 15:45:11 -0400 Received: by redhat.com (Postfix, from userid 201) id A85D01B854; Fri, 17 May 2002 15:45:11 -0400 (EDT) Date: Fri, 17 May 2002 14:52:00 -0000 From: Christopher Faylor To: cygwin@cygwin.com Subject: Re: setup.exe 2.218.2.8/9 broken Message-ID: <20020517194511.GB19177@redhat.com> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23.1i X-SW-Source: 2002-05/txt/msg01159.txt.bz2 On Fri, May 17, 2002 at 02:06:36PM -0400, Harig, Mark A. wrote: >Chuck Wilson wrote: >>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: IMO, this is an extremely minor issue and one which is easily corrected. If someone chooses a populated directory to hold their downloaded files then, well, > 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. The user should consider this a valuable learning experience that they should not be using an existing directory to hold an application's download files. This is consistent with the UNIX philsophy of giving someone enough rope to drown themselves, if they want. >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. I don't agree. However, this is really not worth discussing any further. Either someone will provide a patch or they won't. I'd urge the main setup.exe contributors to continue to work on important issues and consider this to be extremely low priority if it actually makes it onto a todo list. That said, however, if setup.exe is actually *defaulting* to using an already populated directory, then that is not good. The default should be changed. That should be easy enough to do and easy enough to confirm. cgf -- 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/