This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [PATCH] Two fixes for setup postinstall handling.
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Sun, 10 Aug 2008 11:29:49 -0400
- Subject: Re: [PATCH] Two fixes for setup postinstall handling.
- References: <010901c8faec$0b194350$9601a8c0@CAM.ARTIMI.COM>
- Reply-to: cygwin-apps at cygwin dot com
On Sun, Aug 10, 2008 at 02:21:48PM +0100, Dave Korn wrote:
>In case it's controversial, I thought I'd post these patches before
>committing anything. The two hunks I've included in one patchfile here
>are in fact separate and orthogonal, I just posted them in one file for
>convenience.
>
>The first hunk finds if bash is in the list of packages that have
>scripts to run and swaps it with the first entry if so. You may feel
>it's crude, but it's also does-what-it-says-on-the-tin, and it's sane:
>we can't possibly run postinstall scripts without a working shell, the
>postinstall script for the shell is what guarantees we have what counts
>as "a working shell" for that purpose, so why not just deliberately say
>"Hey, we have to do this first and we know we have to do it first so
>let's just do it first"?
If this is necessary, I don't like the idea of special casing bash.
Can't we add a keyword to setup.ini so this could be configurable?
> The second hunk checks for the return code from bash that means 'bad
>interpreter', i.e. when it has been unable to invoke the executable listed
>after a shebang. We can't know in the general case of an error during
>execution whether the script run and/or how close it got to completion
>before it failed, but in this one specific case we can know for absolute
>certain that it didn't run not even a little bit, so let's do ourselves a
>favour and not mark it done. I think that means that people who have
>failures could just re-run and click straight through setup.exe and get the
>scripts to run without having to set everything to "Reinstall" as is
>currently the case. I'm not mad keen on a hardcoded 126 in there, but AFAI
>could find out there's no public header with bash error codes in it -
>someone please correct me if they know better.
>
> The first hunk could be obviated by doing away with postinstall scripts
>for bash, but it a) is perhaps an easier change than respinning a fresh bash
>release,
? How is patching, reviewing the patch, rebuilding, and releasing setup.exe
easier than Eric releasing a new version of bash which just installs sh.exe
unconditionally?
>b) is defensive programming - it's always going to be the case that, if
>there are any scripts needed to install the shell, they should be the
>very first thing we do, and this means that should a situation ever
>arise in the future where we find ourselves needing bash postinstall
>scripts, they will just work and we won't regress to the situation we
>find ourselves in now.
Sorry but I'm not yet convinced that this is necessary.
cgf