Upload: bash-3.0-4 [test]

Corinna Vinschen corinna-cygwin@cygwin.com
Tue Jul 5 18:04:00 GMT 2005

On Jul  5 13:55, Igor Pechtchanski wrote:
> On Tue, 5 Jul 2005, Corinna Vinschen wrote:
> > On Jul  5 13:32, Igor Pechtchanski wrote:
> > > 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.
> >
> > Aren't we making this all too complicated?  If you ask me, we should
> > release a new setup.exe which refuses to deinstall the packages from the
> > "Base" category.  If anybody suffers from manual deinstalles, it's
> > entirely a user fault and the person deserves all types of suffering.
> It's not a question of deinstalling -- this also happens during upgrades.

If it happens within an upgrade, then a DLL has been removed which
shouldn't be removed.  Isn't avoiding this situation the purpose of
keeping multiple package versions around like, for instance ncurses6,
ncurses7, ncurses8?  So, if the old foo depends on a lib bar, which is
incompatibly replaced by it's successor, then the successor should be
a new package bar2, right?


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          mailto:cygwin@cygwin.com
Red Hat, Inc.

More information about the Cygwin-apps mailing list