On 12/08/2010 06:44, Andy Koppe wrote:
On 23 July 2010 18:45, Jon TURNEY wrote:
Here's a small patch for setup.exe which causes setup to indicate if a
postinstall script didn't run successfully.
This should help avoid the situation where the postinstall scripts fail to
run and the user has a broken installation, but they don't notice until they
try to run something which relies on postinstall scripts, e.g [1] and I'm
sure there are other examples.
[1] http://cygwin.com/ml/cygwin-xfree/2010-07/msg00084.html
ChangeLog:
* postinstall.cc : Note if any postinstall script fails and tell
the user with an error messagebox
* script.cc (run): Don't rename script as .done if it didn't run
successfully
Shall we tone down the error box here a little bit? A postinstall
failure in some obscure package that might only have been installed
due to the user selecting 'All' won't actually impact on the use of
Cygwin. I think the current wording will unnecessarily scare off
unexperienced users who wouldn't know how to correct these failures.
Suggestion below.
Andy
Index: postinstallresults.cc
===================================================================
RCS file: /cvs/cygwin-apps/setup/postinstallresults.cc,v
retrieving revision 1.1
diff -u -r1.1 postinstallresults.cc
--- postinstallresults.cc 29 Jul 2010 13:09:04 -0000 1.1
+++ postinstallresults.cc 12 Aug 2010 05:39:21 -0000
@@ -57,10 +57,10 @@
// one or more postinstall scripts failed to run successfully
// installation may be broken
MessageBox (NULL,
- "You will need to investigate and correct these errors "
- "before your Cygwin installation will function properly.\n"
- "Check setup.log for details.",
- "ERROR - postinstall scripts failed",
+ "The affected packages and those that depend\n"
+ "on them may not function properly.\n"
+ "Check /var/log/setup.log for details.",
+ "ERROR - postinstall script failures",
MB_OK | MB_ICONERROR | MB_SETFOREGROUND | MB_TOPMOST);
return IDD_DESKTOP;
I agree, I was going to suggest something like this. I'm afraid I just copied
and adjusted the text from the dependencies declined dialog.
It might be better to point to setup.log.full since it seems that contains the
actual output from the failing command, and only from the most recent run of
setup.
