Corinna Vinschen writes: >> I would consider this a release candidate. Some more testing with >> interactive and ad-hoc installs would be useful, though. > > How do you want to handle this? We don't have real provisions for > setup.exe release candidates.
True. At the moment it'd probably mean that some other folks on this list try it and give their GTG. They'd either have to build it themselves or maybe use the AppVeyor build from Jon Turney. > Maybe we should change how we provide setup updates in future? > > I have a vague idea that setup should ideally be part of the Cygwin > distro package set. So setup updates itself, and it would be possible > to handle public "test" releases. We could add a new key to setup.ini that indicates the existence of a test version and have setup ask if the user would maybe want to use that instead. Ideally setup would then download and exec it if the user choses to run it. I don't have code ready to do that, though… Another problem that needs to be solved is to know how much exposure the new setup.exe really had to decide if it's good for release. > The issue of overwriting setup while setup is running could be worked > around by setup first copying itself to a intermediate filename (e.g. > .setup.exe) and then exce'ing that copy. > > Other ideas how we could handle this? As said before, the idea that setup.exe needs to be entirely self-contained is both an advantage and limiting what it can do. I haven't had time yet to check, but a minimal Cygwin install system w/ busybox might not be too large compared to the connectivity demands of todays' Windows itself. Here setup.exe would just need to unpack the current image of the install system and provide the GUI to pick the packages and control the actual installation. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds