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 [EMAIL PROTECTED] >with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
