This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)


Robert Collins wrote:

> On 25 Jul 2001 14:08:02 -0700, Dario Alcocer wrote:
> 
>>>>>>>"Bernard" == Bernard Dautrevaux <Dautrevaux@microprocess.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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]