Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Subject: RE: setup.exe 2.218.2.8/9 broken MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 18 May 2002 10:08:52 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Robert Collins" To: "Harig, Mark A." , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g4I0AaG10466 > -----Original Message----- > From: Harig, Mark A. [mailto:maharig AT idirect DOT net] > Sent: Saturday, May 18, 2002 4:07 AM > > 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 is because setup cannot tell the difference. Can it be taught to tell the difference? Possibly, but I won't be doing the teaching. > 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"). I keep all mine in a single separate directory tree too. This functionality will never go away. It's keeping setup's 'local package dir' at a logical node in the tree rather than a leaf that is the problem. > 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. It's the same sort of error to setup. I'll accept a patch that can -accurately- differentiate between the problems. Don't diff against the distributed source, diff against CVS for this please, as the HEAD parser is somewhat...different. Rob -- 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/