This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: Upload: bash-3.0-4 [test]
On Tue, 5 Jul 2005, Eric Blake wrote:
> > > > 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.
Perhaps we are. I'm just uncomfortable with running an old version of
some package after upgrading to the new version.
> 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).
I disagree. The removal may happen via a dummy upgrade helper, for
example. As I said above, I'm uncomfortable with running a program when
it's not guaranteed that all of its dependencies are present. Sure, we
can prevent this by being careful, but someone is bound to screw up sooner
or later -- isn't it better to avoid the whole situation altogether?
This may not apply to the bash/ash interaction, BTW, but in general I
think we should design it right from the start.
> [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?]
Even if it's released soon, this won't help, as the dependency is not of
the new package, but of the old one, and setup doesn't check for that.
> 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.
Ugh, that's bad. You'll need to make bash depend on all libraries that
all previous versions of bash ever depended on -- remember, the old bash
could be *any version*.
> > > 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 do. :-) Run "cmp /bin/bash /bin/sh" in the preremove script, when
you're guaranteed that if /bin/sh is bash, it's the exact same bash that
is currently installed.
> 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.
Unfortunately, it would, since the popup is modal. Welcome to Windows.
> > > 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.
Why all this effort of avoiding removing /bin/sh? The two times the
preremove script would be run are on uninstall and on upgrade. Uninstall
should be disallowed by other means (e.g., explicitly checking in setup
when packages in Base are uninstalled), and upgrades are harmless, IMO.
So why try to avoid removing /bin/sh in a preremove script?
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pechtcha@cs.nyu.edu
ZZZzz /,`.-'`' -. ;-;;,_ igor@watson.ibm.com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT