Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <3B5F5731.1090000@ece.gatech.edu>
Date: Wed, 25 Jul 2001 19:33:05 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713
X-Accept-Language: en-us
MIME-Version: 1.0
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC: Dario Alcocer <alcocer AT helixdigital DOT com>, cygwin AT cygwin DOT com,
        Bernard Dautrevaux <Dautrevaux AT microprocess DOT com>
Subject: Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)
References: <17B78BDF120BD411B70100500422FC6309E2FD AT IIS000> 	<15199 DOT 13618 DOT 671411 DOT 755243 AT coyote DOT priv DOT helixdigital DOT com> <996103548 DOT 18053 DOT 7 DOT camel AT lifelesswks>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Robert Collins wrote:

> On 25 Jul 2001 14:08:02 -0700, Dario Alcocer wrote:
> 
>>>>>>>"Bernard" == Bernard Dautrevaux <Dautrevaux AT microprocess DOT com> writes:
>>>>>>>
>>    Bernard> Or as the installer user interface is tcl/tk-based, you
>>    Bernard> can look at FreeWrap
>>    Bernard> (http://home.nycap.rr.com/dlabelle/freewrap/freewrap.html). Its
>>    Bernard> neat and works quite well; moreover the tcl/tk installer
>>    Bernard> in this case do not NEED cygwin, so can unpack the basic
>>    Bernard> bootstrap environment without any problem).
>>
>>Yes, I guess this would work as well.  However, the main reason I
>>didn't want eliminate the Cygwin DLL was that I wanted to use ash to
>>run the RPM package post-install/pre-uninstall scripts with it.  I
>>guess I could find a Win32 Bourne-compatible shell that didn't require
>>Cygwin to replace ash, but that would still leave me looking for
>>Win32-only ports of the other utilities that might be required by the
>>scripts (e.g. awk, sed, cut, paste etc.)
>>
>>In the end, it just seemed simpler that, rather than trying to avoid
>>including Cygwin in the installer (and miss out on all that
>>functionality), I should instead find a way to use cygwin1.dll and
>>avoid the pitfalls instead.  I decided on a two-stage install process;
>>the first stage would check for a duplicate cygwin1.dll loaded in
>>memory (and abort with a message if one was found), and the second
>>stage would be the actual Tcl/Tk installer.
>>
> 
> Unfortunately that still has the potential for trouble:
> 
> 1) consider an ash script run when updating ash?
> 2) Consider other scripts running when updating ash?
> 3) Consider rpm updating itself ?
> 
> I'm not trying to throw cold water on this - just to raise some
> considerations.
> 
> IMO, the setup program should update cygwin1.dll; force a reboot if
> needed to get the new dll copied in (MS document how to do this); then
> call into cygwin linked programs to do the real work (including rpm).
> Cygwin1.dll needs to provide an abstracted replace-file-on-reboot
> functionality, and the installing package stops as soon as such an
> occurence happens triggering another reboot...
> 


**IF** you're going to pursue this, The Right Way(tm) is to build a 
special cygwin1.dll AND import lib environment, where the "shared memory 
region name" is different -- and perhaps the dll name itself, as well. 
Also, it should use a different registry key for mounts and such, 
probably. (Check the cygwin archives wrt. error_start and gdb for some 
info on how to do the "shared memory region name" thing).  Then, build 
your special ash and rpm and db and utils within that environment (you 
may need to also build gcc?)

Okay, so no2 you've got a nice, self-contained "cygwin"-based 
mini-environment that will not interfere with a "real" cygwin 
environment.  So, the mini-environment should be able to update anything 
in the real environment, with the usual caveats about files in-use by 
"real" cygwin programs.

The difficulty here is you've got to maintain TWO separate binaries for 
your core utilities -- one set of (cygwin itself, ash, rpm, db, etc) for 
the "real" system and one set for the "mini" environment.

--Chuck






--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/