Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Tue, 25 Oct 2005 09:55:00 -0400 (EDT)
From: Igor Pechtchanski <pechtcha AT cs DOT nyu DOT edu>
Reply-To: cygwin AT cygwin DOT com
To: cygwin AT cygwin DOT com
Subject: Re: cygwin-setup & rebaseall
In-Reply-To: <435DBB31.5C164C83@dessent.net>
Message-ID: <Pine.GSO.4.63.0510250952420.9635@slinky.cs.nyu.edu>
References: <Pine DOT LNX DOT 4 DOT 64 DOT 0510241321510 DOT 5697 AT asterix> <435D743F DOT EDB6FBB9 AT dessent DOT net>  <Pine DOT LNX DOT 4 DOT 64 DOT 0510242312570 DOT 8868 AT asterix> <435DBB31 DOT 5C164C83 AT dessent DOT net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 24 Oct 2005, Brian Dessent wrote:

> Satish Balay wrote:
>
> > [maybe the fix is: for any package that is likely to break - add a
> > flag - which triggers setup to run rebaseall - after
> > install/upgrade. So no overhead for pacakges that don't break - but
> > always overhead for packages that break.]
>
> Automatically running rebaseall from setup.exe has issues too.  For one
> thing, it would run into problems if the user had programs or services
> running.  The rebaseall script bails if it cannot write to a DLL, so
> unless the user was very careful to close all running programs, it would
> fail in almost all cases.  Rebaseall would have to be modified to rebase
> in-use DLLs, but this would require the user to reboot.  And, somehow
> this would have to be communicated to setup.exe so it could notify the
> user.  Plus, consider if setup.exe installed a DLL that was in use
> (writing it to name.dll.new, and scheduling that for replacement at next
> boot) and then rebaseall was run.  The rebaseall script would have to
> know to rebase name.dll.new and not name.dll.  It just gets more and
> more complicated.  The only workable solution would be to incorporate
> the entire rebaseall functionality internally into setup.exe, which is
> not an insignificant undertaking, and one which no one is eager to
> undertake.

Plus, as Jason mentions, rebasing corrupts some DLLs.  So, until a robust
solution for that is found, automatically rebasing in setup.exe isn't such
a hot idea.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor AT watson DOT ibm DOT com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/