This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: NOTICE for all package maintainers with faulty post-install scripts


> On Thu, Aug 12, 2010 at 09:56:49AM -0400, Andrew Schulman wrote:
> >> Thanks to Jon Turney's recent patch we've discovered that many
> >> post-install packages were previously failing silently. 
> >
> >Failing silently... so what is the preferred protocol in case a
> >post-install script fails?  Emit a message to stderr, which will be caught
> >and shown to the user?
> 
> There is apparently a disconnect here.  setup.exe now lets you know if a
> script fails.  Scripts are not supposed to fail.  Some scripts are
> routinely failing and should be fixed.
> 
> If your script fails for a valid reason then of course exiting with a
> non-zero status is the way to go.  That is what the new dialog box was
> intended to catch.
> 
> If one of your scripts does fail then you should work out why with the
> affected user and take steps to make sure that it doesn't fail.

Let me be sure first that I understand the new functionality.  By "fail" we
mean exiting with a non-zero status, correct?  So when a postinstall or
preremove script exits non-zero, the user will be alerted of that fact?
And maybe output to stderr and/or stdout provided, in the hope that it will
help to diagnose the problem?

I may just be confused by your phrase "failing silently".  I'm just trying
to figure out how if at all I need to adjust my postinstall/preremove
scripts to check for non-zero exit statuses and try to provide useful
output about them.  Most of those scripts are short, but some contain
multiple commands, any of which could fail for any number of reasons that
are hard to predict.  Once a problem is well-known I can add code to check
for it and provide a useful message, but until then, either silence or a
possibly not very enlightening error message is going to be the usual mode
of failure.

Anyway, I agreed that failure shouldn't happen routinely, it's good that
failures are now going to be brought to our attention, and packagers should
fix those problems when they get reported, which I guess was your main
point.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]