This is the mail archive of the
mailing list for the Cygwin project.
- From: Achim Gratz <Stromeko at nexgo dot de>
- To: cygwin-apps at cygwin dot com
- Date: Sat, 08 Aug 2015 07:22:27 +0200
- Subject: Re: setup
- Authentication-results: sourceware.org; auth=none
- References: <87vbcwfdvw dot fsf at Rainer dot invalid> <87r3nkfaxn dot fsf at Rainer dot invalid> <87mvy8f8dz dot fsf at Rainer dot invalid> <20150803202908 dot GI17917 at calimero dot vinschen dot de> <87a8u8f4s5 dot fsf at Rainer dot invalid> <871tfidhrm dot fsf at Rainer dot invalid> <20150805080833 dot GT17917 at calimero dot vinschen dot de> <87614tn3nm dot fsf at Rainer dot invalid> <20150806100338 dot GY17917 at calimero dot vinschen dot de> <87d1z0if40 dot fsf at Rainer dot invalid> <20150807194737 dot GO12475 at calimero dot vinschen dot de>
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.
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf rackAttack: