Williams, Gerald S (Jerry) wrote:
installer when needed/requested. The base Cygwin installer could then be done using MSI or whatever and could initiate reboots/etc. as needed before starting the package updater.
Rebooting is a cop-out in this case. All the setup program has to do is stop running services before starting the upgrade.
This gets me into a different subject: one of the things that is more difficult about Cygwin than it has to be is that you have to run command-line scripts to set up services like sshd. If the installer could manage this, even if only to start a Cygwin window running the script, that would be helpful. A side benefit of this is that the service names would thereby be standardized, which would then let the installer search the service set for those that should be stopped before upgrading.
This only applies to the NT-based kernel case, of course. I wouldn't care if the installer had to reboot the system for 9x kernels.
I do like the idea of writing the next version in some kind of scripting language. It allows more features per line of code, so more features get written in a given amount of programmer time. The trick, of course, is how to bootstrap the scripting environment on the first install. Probably a "real" Windows installer could manage this, using a temporary private version of cygwin.dll to run the scripting environment.