This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: setup

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 Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgphuxJfugk2Q.pgp
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]