setup
Corinna Vinschen
corinna-cygwin@cygwin.com
Mon Aug 10 09:18:00 GMT 2015
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20150810/222967b5/attachment.sig>
More information about the Cygwin-apps
mailing list