RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Robert Collins]

On 26 Jul 2001 17:49:50 -0700, Dario Alcocer wrote:
> >>>>> "Robert" == Robert Collins <robert.collins@itdomain.com.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.
What if:
the irt cygwin1.dll is incompatible with the installed, running
cygwin1.dll - so that any attempt to call cygwin1.dll functions (which
the irt uses?) results in a crash.
I covered ina different reply the mechanics of a different shared memory
identifier.

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

>     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.
OK. You might get a smaller size if they were stripped? (1.5 Mb
compressed _sounds_ big so I'm guessing at that.).
 
>     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.
Yes, thats good - however the reboot needs to use the replace on reboot
mechanism - see below.

> 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.
As long as you have permissions to shut them down :]. I can _assure_
you, given past experience, that users don't easily comprehend "login as
administrator, and set the service startup to manual, then eiether stop
the service and retry or reboot". Microsoft have had to release
technotes detailing how to do that for things like Exchange Server. A
good installer covers that base - and it's a uniquely win32 base
unfortunately.
 
>     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 :-)
Yah. I'll skip for now :]
 
> 
> 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...
Finding time is not always easy is it! Still, it's sounding good.

As an aside, cygwin-the-distro to me is a lot closer to debian GNU/Linux
than Redhat GNU/Linux - the constantly evolving packages, with firm
policies on quality and responsibility. From that angle, I'd like to see
the current "run-setup every now and then, download the new stuff, and
watch it install" process remain, a


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