Linda W wrote: > But all of this discussion is moot if there is no high level > interest in providing 3rd party links or a cygwin-contrib > section to setup. Having all package dependancies specified > in the "setup" format _might_ be another obstacle to 3rd > party ports of existing rpm packages. Rpm could be enhanced > to work with/around Window's file-copy semantics -- if by > no other method that using "sysinternals.com" "movefile" > utility which allows replacing of "in use" files (followed > by a reboot to finish the install just as setup does).
Well, there have been recent discussion about reinventing setup.exe. Some suggested a front-end/back-end solution, where there is a GUI lying on top of command line utilities to do the heavy lifting. Others brought up moving to existing packaging mechanisms like RPM or pkgsrc. One thing is clear though, you can't just say "rpm is nice" and start using that. For one thing, the file replacement issue is nowhere near as simplistic as you make it out. "In use replacement" under windows amounts to placing an entry in the registry telling the system to move file A to file B upon next restart, and then put a copy of the updated in-use file at location A and prompt for a reboot. There's no magic, there's no getting around the basic paradigm of windows filesystems that require that all outstanding handles of a file be closed before it can be deleted. rpm packages assume that they can replace in-use files and then HUP whatever had copies of those libraries in memory, and all will be fine. It just doesn't work the same under windows. I can find no such utility "movefile" on sysinternals, but I think you might be referring to something along the lines of the "inuse" utility that is included in the windows resource kit. Even still, there is no way a tool like that could be depended upon for an open source project like Cygwin. Someone would have to write an implementation of the util under a proper OSI license in order for it to be considered a necessary and dependent part of the project. It seems clear to most everyone that participated in those "setup.exe sucks" threads that there must be some kind of "bootstrap setup" at the very least, that is not dependent on the cygwin DLL that can install/upgrade core packages. You might be able to get away then with using a richer environment (like tcl, perl, cygwin-ported-rpm, whatever) for the other things. But the point I'm trying to make here is the following: Cygwin package management differs fundamentally from *nix, so you can't just drop in *nix package tools without some modifications. Someone somewhere will have to write some code and until that happens there will be no progress. On top of that, I submit that it's not the binary package layout that's an issue to getting more official packages. The Cygwin packaging format is quite simple, and if someone is motivated it should be rather easy to take a source tarball that compiles cleanly and turn it into a cygwin package. The setup.hint authoring is close to trivial. The thing that seems to prevent people from contributing packages is the need for there to be someone in the hotseat to take ownership of the package. It seems rather often that someone will say "I've been able to port app X to cygwin without too much trouble but I can't commit to being a package maintainer." This has nothing to do with the details of the binary package format used, and everything to do with redhat/cygwin drivers wanting (...a very minor level of...) accountability for all official packages. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
