[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: Hello all



>The one major problem I see with this whole setup is the one you listed as
>problem number 1, which is that Win32 won't allow for any interactions with
>a file that is already opened, and this makes for some interesting
challenges

I guess this is why all of the install tools (InstallShield, etc) always
recommend exiting all programs before running setup.  setup.exe could do
the same.  It would be consistend with other Windows app. behavior.

>in the area of updating/upgrading already running processes, especially
>the cygwin1.dll file.  Additionally, there is the whole "chicken/egg"
problem.
>(How do you get/install dpkg to run dpkg to install dpkg.....)

I may be ignorant of cygwin1.dll's purpose, but isn't it a kernel?  It
provides system calls like fork and open, does it not?  If so, upgrading
cygwin1.dll is like upgrading the Linux kernel.  It requires a reboot.
Maybe a trick is needed to upgrade this dll.  I.e. what if each time this
dll needs to be loaded, a copy of it is loaded instead.  This way, you
can still modify the original copy after the new copy is running.
Hopefully,
when all cygwin apps exit, the cygwin1.dll is unloaded and deletes itself.

I have not done this type of wizardry myself, so it is just a suggestion.

--jc
--
jching@adtech-inc.com     Adtech, Inc.    (808) 734-3300


>-----Original Message-----
>From: Mark Paulus [mailto:mpaulus78@earthlink.net]
>Sent: Thursday, November 15, 2001 6:13 AM
>To: debian-win32@lists.debian.org
>Subject: Re: Hello all
>
>
>On Thu, 15 Nov 2001 09:58:59 +1100, Robert Collins wrote:
>
>>
>>1) Replacing open files. Say that setup uses berkley db3 as a .dll.
>>Setup can not replace that .dll itself - and any dpkg/rpm style port
>>will assume that it can replace that .dll. I've made a beta release of
>>setup.exe that *can* do this, but it needs testing and work.
>>2) Porting issues. Setup.exe is a win32 program, not a cygwin program.
>>It could dynamically open cygwin1.dll, once it's been 
>installed, but the
>>core functionality, to grab packages off the net and install 
>cygwin1.dll
>>in the correct place with the correct permissions has to be built in.
>>Thus any dpkg port that will bootstrap debian-w32 needs to be a native
>>win32 program, statically linked to any libraries, and able 
>to bootstrap
>>itself to get any required .dll's.
>>
>>I think it would be a shame for users to have to bootstrap cygwin from
>>cygwin.com, and then grab a *different* installer for debian-w32. IMO
>>setup.exe should be a direct bootstrap. Also I think that 
>maintaining a
>>separate tree of binaries and source does not make sense for Cygwin
>>today. There simply are not enough kernel developers or package
>>maintainers at this point. It would be great to see some of the debian
>>features and capabilities brought to the existing environment IMO.
>
>In the interests of honest discussion, I'm wondering what would be
>the problem with having cygwin's setup using dpkg/apt as it's backend.
>This would allow those users who like a graphical front end to 
>use cygwin's
>gui setup app.  And, those who are more comfortable with a CLI to use
>the standard dselect/dpkg/apt interfaces.  
>
>This would seem to offer several benefits:
>1:  There already is an established policy for package porting 
>and inclusion 
>within a given release cycle.
>2:  The tools are already written and very rich in their 
>functionallity.
>3:  The porting process is well defined and can be quickly and easily 
>leveraged to include this new w32/un*x architecture (barring 
>some new "glue"
>code requiring development....
>4:  Quick access to security updates
>5:  Established practices and archive forums to distribution 
>and delivery of
>updates and new packages.
>
>The one major problem I see with this whole setup is the one 
>you listed as
>problem number 1, which is that Win32 won't allow for any 
>interactions with
>a file that is already opened, and this makes for some 
>interesting challenges
>in the area of updating/upgrading already running processes, especially
>the cygwin1.dll file.  Additionally, there is the whole 
>"chicken/egg" problem.
>(How do you get/install dpkg to run dpkg to install dpkg.....)
>
>
>
>>
>>(Can you tell I'm walking a thin line here ?)
>>
>>Anyway,
>>just letting you know I'm interested in how this goes,
>>Rob
>>
>>
>>-- 
>>To UNSUBSCRIBE, email to debian-win32-request@lists.debian.org
>>with a subject of "unsubscribe". Trouble? Contact 
>listmaster@lists.debian.org
>>
>
>
>
>
>-- 
>To UNSUBSCRIBE, email to debian-win32-request@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact 
>listmaster@lists.debian.org
>



Reply to: