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]


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

Maybe we are getting ahead of ourselves.  libreadline, libintl, and
libiconv are all versioned libraries, maintained by capable people who
understand the importance of maintaining backwards compatibility.
Upgrading bash and the libraries simultaneously should not break the
older version of bash; even if the library API changes, it would mean
the introduction of a new package (such as libreadline7, rather than
breaking libreadline6).  All I can think of is upgrading bash while
removing one of the libraries, in which case the user deserves the
"Can't locate DLL" popup (that is, if the new bash is even runnable without
those same libraries just deleted).  [side note - when is the new setup.exe
ever going to be declared ready for release, so that users are more
forcefully warned that they are deselecting required dependencies?]
And even new versions of bash that depend on new versions of
libraries can still list the old library package name as a dependency,
to ensure that the upgrade does not delete the old library.

> >
> > Actually that would be covered by postinstall scripts which don't use
> > /bin/sh at all.
> 
> Yep, that's what I meant.

OK, then, does anyone else have ideas on how to determine if /bin/sh
is ash with resorting to running it, and without resorting to packing
an ever-increasing list of known md5sums of all prior versions in the
bash postinstall script?  I still think parsing '/bin/sh --version' is the
cleanest approach, even if it does lead to the risk of a popup box if
the user uninstalled a library.

What message gets printed by bash when trying to invoke an executable
whose dependent library can't be found?  Even if the user does get
the popup box, the bash script can still be made to treat that the same
as /bin/sh not being installed, as its trigger to update to the current
version of bash.  In other words, the popup box would be annoying,
but would not prevent the upgrade from happening.

> > I still don't like the idea of a preremove script removing /bin/sh under
> > whatever circumstances.
> 
> How about using a dummy executable that doesn't depend on anything and
> does nothing but print out some pre-defined message, and copying that to
> /bin/sh in the preremove script?  That way, there will always be a
> (non-working, but who cares) /bin/sh...  I was going to suggest
> /bin/false, but the new version actually depends on cygintl-3.dll and
> cygiconv-2.dll -- go figure.

Again, do we need to go to this much effort?  If the postinstall script
can upgrade bash gracefully (insofar as the user is not running /bin/sh
concurrently in the background and has not manually deselected
dependencies), then leaving /bin/sh untouched at preremove time
is the simplest course of action.

--
Eric Blake



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