Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Injected-Via-Gmane: http://gmane.org/ To: cygwin AT cygwin DOT com From: Andrew DeFaria Subject: Re: Upgrading Cygwin - postinstall difficulties? Date: Tue, 16 Sep 2003 10:30:25 -0700 Lines: 21 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet AT sea DOT gmane DOT org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, zh In-Reply-To: Igor Pechtchanski wrote: > This is not under setup's control. Postinstall scripts are written by > individual package maintainers. Most of them *are* reexecutable, or, > at least, don't do anything that can't be redone. Some, however, > modify existing state of the system, either in-place or conditionally > on the non-existence of this previous state (i.e., new install). In > both of > these cases, there's a potential for failure, and the scripts will > probably not be reexecutable. A list of such scripts might be a useful > thing to have in the archives. What I was saying is that the writers of postinstall scripts should be mindful that their scripts are re-runnable. And for the few instances where a postinstall script relies on things like the non-existence of a previous state that they should perhaps provide a option, say -reinstall, that would set the situation as if it was a new install. === Obligatory witty saying: Always remember you're unique... Just like everyone else. -- 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/