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]

[PATCH] Two fixes for setup postinstall handling.



    Hi all,

  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"?

  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, and 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.



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Attachment: setup-postinstall-patch.diff
Description: Binary data


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