On Aug  8 07:22, Achim Gratz wrote:
> 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.

Link?  I'm using setup with the -m option exclusively so I'm mostly
interested that this still works.  However, you might want to make a
quick list what scenarios you want to have tested as well.  I try to
do that over the next couple of days and hopfully other maintainers
try, too.

> > 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.

IIUC, you mean that the current method of downloading setup only from
sware should be maintained?  What kind of "key" are you talking about?

> 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.

That's a general problem.  I'm not sure how much exposure the Cygwin
test DLLs really have, either.  I'm reasonable sure that some of you
maintainers are using them, but otherwise it's a bit of a black hole.

> > 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.

Not sure I follow.  How would such an install system look like?
I have a vague notion that busybox could run the scripts, but there
are installation path issues and requirements of some postinstall
scripts which might not be suffiecently handled by busybox.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat