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: Upload: bash-3.0-4 [test]


> On Tue, 5 Jul 2005, Eric Blake wrote:
> > #!/bin/bash
> > # If /bin/sh is missing, ash, or bash, upgrade it to the current bash.
> > case `/bin/sh.exe --version 2>&1
> 
> FYI, this is missing a closing backtick and the "in".

Yep, you caught me typing on the fly instead of pasting a tested script.

Should man/man1/sh.1 always belong to bash, or should I use readlink
to ensure that I am only upgrading that link if it was to ash?  In other
words, for users smart enough to replace /bin/sh with zsh, are they
also going to want to replace the /bin/sh manpage and expect that
replacement to be preserved?

> This isn't good enough -- I think you do need a preremove script.  I've
> been trying to figure out why the no-preremove solution seems wrong, and
> came up with the following scenario: suppose bash is linked against an
> older libreadline, and the user upgrades both bash and libreadline to
> newer versions.  /bin/sh will be a copy of the old version of bash, but
> after the upgrade it won't have the necessary DLLs.  So, running the
> postinstall script (with "/bin/sh --version") will result in a "Can't
> locate DLL" popup, which should be a no-no in a postinstall script.

Thanks for thinking through these issues.  I think we are closing in on
the best solution, and yes, I agree with your argument that bash should
keep its preremove script.  Is there anything (in cygutils, perhaps) that
can request a replace-on-reboot if ln fails in the postinstall because
/bin/sh was in use during the upgrade?  Then again, we already
recommend that all cygwin processes be stopped during an upgrade.

--
Eric Blake



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