Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
From: Dario Alcocer <alcocer AT helixdigital DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15200.47790.702008.800618@coyote.priv.helixdigital.com>
Date: Thu, 26 Jul 2001 17:49:50 -0700
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
Cc: cygwin AT cygwin DOT com
Subject: RE: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)
In-Reply-To: <996191259.22763.10.camel@lifelesswks>
References: <17B78BDF120BD411B70100500422FC6309E2FD AT IIS000>
	<15199 DOT 13618 DOT 671411 DOT 755243 AT coyote DOT priv DOT helixdigital DOT com>
	<996103548 DOT 18053 DOT 7 DOT camel AT lifelesswks>
	<15200 DOT 14214 DOT 419912 DOT 961927 AT coyote DOT priv DOT helixdigital DOT com>
	<996191259 DOT 22763 DOT 10 DOT camel AT lifelesswks>
X-Mailer: VM 6.76 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid

>>>>> "Robert" == Robert Collins <robert DOT collins AT itdomain DOT com DOT au> writes:

    Robert> As Chuck has mentioned, that cygwin1.dll should have a
    Robert> different shared memory region identifier, to prevent
    Robert> crashes :}.

Just curious; can't we avoid a specially built version of cygwin1.dll
by making sure that cygwin1.dll isn't loaded when the installer runs?
Making a special verion of cygwin1.dll could add more confusion.

    Robert> ok... how do you update that installer toolbox?

The installer toolbox (drat, I should have called it the IRT, for
"installer run-time") would be updated only when:

    * a cygwin1.dll bug has been fixed that affects the installer

    * a cygwin1.dll feature has been added that is needed by a
      newer version of the installer.

In either of these cases, a new self-extracting binary for the
installer would be built which would include the updated installer
toolbox.  Note that the installer toolbox, AKA installer run-time, is
only used by the installer; the installed Cygwin would never use these
tools.

    Robert> Unix allows the deletion and replacement of open files,
    Robert> win32 doesn't.  Thats the root of the problems I'm
    Robert> highlighting - so no, Linux is not as badly off as we are
    Robert> :}.

OK, I didn't understand your original point.  Yes, I think the
solution here is to make sure that the RPM packages should not
included scripts that would exhibit this problem.

    Robert> Again, how do the users update the toolbox? Or do they
    Robert> download a 5mb install for the toolbox when it needs
    Robert> updating?

Users would not update the installer run-time, only the installer's
maintainer.  Since the installer run-time would be included in the
self-extracting installer (and would be delete automatically by the
installer after it's completed its job), the users would never really
have to know about it, or worry about updating it.  In fact, I believe
that installers built with InstallShield work in this fashion; they
can unpack a series of files to C:\WINDOWS\TEMP and run a second-stage
installer from there.

Regarding the size of the installer run-time, my current environment
is 1.5M compressed.  Since the stub EXE that would be prepended to
this archive to make it self-extracting would probably be only about
10-50KB, I'd guess that the self-extracting installer would not be
much bigger than 1.5M.  While this makes it considerably bigger than
the current setup.exe (~239K), it can still be downloaded in a
reasonable amount of time (6.9 minutes @ 28.8Kbps, 3.6 minutes @
56Kbps.) The biggest files in the run-time are cygwin1.dll, rpm.exe,
cygtk80.dll, and cygtcl80.dll.

    Robert> Uhmm, assuming the user actually knows whats going
    Robert> on. Consider a user that is not the sysadmin of the
    Robert> machine, and doesn't know that sshd is running. In theory,
    Robert> yes with user cooperation, you can do this. In practice I
    Robert> suspect that saying "we have installed a new version of
    Robert> cygwin1.dll, to make it take effect reboot your machine"
    Robert> will be less prone to support questions.

OK, how about adding two buttons on the dialog, "Retry" and "Reboot",
making Reboot the default choice.  The dialog box can tell the user to
shut down the Cygwin apps that were found and click on retry, or they
press Enter and accept the default action, which would reboot the
machine, clearing the loaded Cygwin DLL from memory.

Of course, even a reboot would probably not help in the scenario you
mentioned; if sshd is being run as a service, then it will *still* be
running after reboot.  In this case, maybe only a SIGTERM or SIGHUP to
the loaded Cygwin apps would work.

    Robert> Cygwin1.dll needs to provide an abstracted
    Robert> replace-file-on-reboot functionality, and the installing
    Robert> package stops as soon as such an occurence happens
    Robert> triggering another reboot...

    Robert> Weeeel, what would be really nice would be a hack to
    Robert> cygwin's delete-on-close queue, to allow the unix "delete
    Robert> this open file, now write a new file with the same name"
    Robert> functionality, with cygwin setting up a replace-on-reboot,
    Robert> and removing that replace-on-reboot if/when the file is
    Robert> actually closed and able to be done manually. _And_ for
    Robert> cygwin linked process, redirecting any opens to the queued
    Robert> replacement file :}.  That way the posix semantics would
    Robert> be present, for most files. However such a hack could be
    Robert> very difficult to do _the right way_... and I'm not going
    Robert> to get sidetracked by it :].

Now *that's* a feature that would be worth adding to cygwin1.dll.
However, I suspect it would be a bear to implement, though :-)

    Robert> Thank you. The developer list has spent a bunch of time
    Robert> tossing around various ideas - that was a synopsis of the
    Robert> critical issues that any cygwin hosted installer has to
    Robert> overcome. (Note that cygwin used to have a cygwin-hosted
    Robert> installer, and moved away from that post B20.1).

Yes, I remember B20.1 somewhat fondly.  I actually made my own CD-ROM
with a very crufty text-based installer (actually, just a Bourne shell
script that would set-up the mount points and unpack a few tar files,
including Andy Piper's Cygwin build of XEmacs.)  Worked great, still
have a copy of it somewhere in my office.

Ever since building this CD-ROM install for B20.1, I've wanted to
re-do it using Tcl/Tk.  Unfortunately, it's taken me nearly four years
to do it...

-- 
Dario Alcocer -- Sr. Software Developer, Helix Digital Inc.
alcocer AT helixdigital DOT com -- http://www.helixdigital.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/