X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=1.7 required=5.0 tests=BAYES_50,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,SPF_HELO_PASS,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By:	sourceware.org
To:	cygwin AT cygwin DOT com
From:	Paul Bibbings <paul DOT bibbings AT gmail DOT com>
Subject:	Setup, update thyself
Date:	Sun, 11 Apr 2010 13:16:22 +0100
Lines:	36
Message-ID:	<87pr266v6x.fsf@gmail.com>
Mime-Version:	1.0
User-Agent:	Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (windows-nt)
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

Given how the process of updating packages using setup.exe can be
handled quite automatically - updates are announced, mirrors catch-up,
and the recent updates can be picked up with a run through setup that
requires no interaction at all except to cycle through the `next's - I'm
wondering how it might be that updating of setup.exe is not itself
managed by this same process.  I am certainly notified if setup.exe is
out of date, which then triggers the manual process of shutting it down,
going to the website, grabbing the latest version and starting again.
Could not this process be integrated into setup itself as "just another
package install" in effect? Notification that setup.exe is out of date -
general package selection is disabled - `Next' etc. downloads setup.exe
as a `package' - automatic restart - continue from here...?

One reason for this thought is that I can envisage environments in
which, whilst internet connectivity is permitted on development
machines, installation and use of a web browser is not, through policy,
say. Outside of this scenerio, there would still appear to be a clear
gain for users generally, making it effectively a complete one-stop
shop.

As an add-on benefit this would ensure that setup.exe was always
up-to-date compared to which ever mirror I chose for my updates.
Mirrors catch up at different rates, and there are recorded complexities
added through caching of web downloads in getting setup.exe.  Yet, if
the updating of setup.exe were to become integrated into the package
updating system in this way, this would then at least ensure that the
version used was at least as up-to-date as the mirror I am using at any
one time.  If setup.exe is a version behind the latest available due to
a lag in mirroring, the so is setup.ini.  No more "setup is out of date
on this mirror, but you'll have to wait for server caching to resolve
before getting a new one."  (Perhaps even no more requesting of http
access to setup.exe. Happy days! :)

Regards

Paul Bibbings


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -