Setup, update thyself

Setup, update thyself

[Paul Bibbings]

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

Re: Setup, update thyself

[Rance Hall]

On Sun, Apr 11, 2010 at 7:16 AM, Paul Bibbings <paul.bibbings@gmail.com> wrote:
> 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...?
>

Excellent idea, but difficult to manage since windows has difficulty
replacing files that are in use.

Windows command shell scripting is well, lacking.

The standard way to do this would be to write a script that wgets (or
other windows alternative) the setup.exe on the web into a staging
area.  Run setup -v or some other appropriate switch to get a version
number on both the cygwin setup and the new one.  If needed replace
them.  and then run your standard update using the new setup.  It
works well, but I may be changing it to a fatal error when setup.exe
changes.  The switch between 1.5 and 1.7 could not have been handled
automatically without some study as to pitfalls, etc.

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

Re: Setup, update thyself

[Warren Young]

On 4/11/2010 1:13 PM, Rance Hall wrote:
>
> The standard way to do this would be to write a script that wgets (or
> other windows alternative) the setup.exe on the web into a staging
> area.

Firefox and Adobe do it with a separate updater program.

I'm not recommending that for Cygwin, but setup.exe could be its own 
updater.  It could make a copy of its own executable to a temp location, 
and launch that with a flag that makes it go fetch and replace the 
non-temp copy and relaunch it.

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

Re: Setup, update thyself

[Alexander Groß]

I invoke setup through a little helper script that updates setup.exe
in case there is a new version on the server.

wget.exe --timestamping http://cygwin.com/setup.exe
runas.exe /user:%USERDOMAIN%\Administrator setup.exe

Auto-update would have a nice touch to it, though.

Alex
--
Alexander Groß
http://therightstuff.de/


2010/4/15 Warren Young <warren@etr-usa.com>
>
> On 4/11/2010 1:13 PM, Rance Hall wrote:
>>
>> The standard way to do this would be to write a script that wgets (or
>> other windows alternative) the setup.exe on the web into a staging
>> area.
>
> Firefox and Adobe do it with a separate updater program.
>
> I'm not recommending that for Cygwin, but setup.exe could be its own updater.  It could make a copy of its own executable to a temp location, and launch that with a flag that makes it go fetch and replace the non-temp copy and relaunch it.

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