> That will be a BIG change for any tools that are not "cygwin-native". If > you are going to make that a goal, why not just convert the tools to > cygwin?
Being a Cygwin user, I am convinced Cygwin installer should not be used. This would confuse users who would have the choice between three distributions. Let's take the example of Apache. A user would have the choice between : - Apache from Cygwin installer, - Native Windows Apache, - W32/Debian Apache. Cygwin installer and dpkg have no knowledge of each other. So what happens if you install Cygwin Apache + W32/Debian apache by error during an upgrade? It may create a conflict, which will convince a normal user to drop BOTH Cygwin and W32/Debian. Do you think this would be possible to follow these steps: 1) Port dpkg to Windows using a static POSIX emulation layer. 2) Create a cygwin.deb package for W32/Windows. This probably means compiling Cygwin under mingw, right? 2) Afterwards, we can start building W32/Debian packages with whatever dependency we want. Cygwin or non-Cygwin. This will give us more freedom. > Why? The only registry manipulation that cygwin does is for the mount > table. The "mount" command does this very well. IApache 2.0 threads have been redesigned for more portability. So why should I use it under Cygwin? If we do not find a way to provide W32/Debian packages for important software (Apache, Python, Tcl, etc..) not linked agains Cygwin, people ***may*** turn to native Windows executables. What do you think of this in technical terms? Can 1) 2) and 3) be done? Thanks for this great project, Best regards, Jean-Michel POURE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
