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: Mon, 10 Aug 2015 18:33:18 +0200
- Subject: Re: setup
- Authentication-results: sourceware.org; auth=none
- References: <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> <874mkawe0c dot fsf at Rainer dot invalid> <20150810091820 dot GB13029 at calimero dot vinschen dot de>
Corinna Vinschen writes:
I'd think Jon needs to give his OK for me to post it or he should post
> I'm using setup with the -m option exclusively so I'm mostly
> interested that this still works.
That's pretty extensively tested by now since that is what I use for the
installations at work.
> 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.
Installs from the internet (with and without proxy) and ad-hoc installs
of single packages and package groups from a local directory that
doesn't have a setup.ini.
> IIUC, you mean that the current method of downloading setup only from
> sware should be maintained? What kind of "key" are you talking about?
Currently the integrity of setup.exe and therefore the whole
installation hinges on it being downloaded from sware via https, so
that's a strong reason to keep it that way.
The "key" I'm talking about was that in addition to "setup-version:" we
could have an additional "setup-trial-version" or something like that
would inform setup that a successor is waiting in the wings.
> 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.
You should at least be able to find out how often they were downloaded.
For setup trial versions this isn't enough, so they'd have to contact
sourceware and HEAD/GET something that indicated success or failure (and
some script to extract that out of the logs on sourceware). It also
must not be sneaky about this, ideally the user consents before the
trial version gets downloaded at all.
> 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.
I have done a few manual installations from a running Cygwin onto a
"cold" installation on the same machine, mainly to switch out the Cygwin
DLL. You need to mount the "other" Cygwin somewhere (I use /mnt/cygwin
or something like that) and then redirect the install root there (tar -C
/mnt/cygwin). The postinstall scripts on the other hand must be started
from within the new Cygwin installation anyway.
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Samples for the Waldorf Blofeld: