This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
RE: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)
>>>>> "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.
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@helixdigital.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/