This is the mail archive of the
mailing list for the Cygwin project.
RE: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)
On 26 Jul 2001 08:30:14 -0700, Dario Alcocer wrote:
> >>>>> "Robert" == Robert Collins <firstname.lastname@example.org> writes:
> Robert> On 25 Jul 2001 14:08:02 -0700, Dario Alcocer wrote:
> >> >>>>> "Bernard" == Bernard Dautrevaux
> >> <Dautrevaux@microprocess.com> writes:
> Robert> Unfortunately that still has the potential for trouble:
> Robert, just to clarify, the second-stage install would have all of
> the Cygwin tools used by the installer in either a temporary directory
> (in the case of a self-extracting installer) or on a CD-ROM (in the
> case of a CD-ROM based installer); let's call this minimum collection
> of RPM tools used by the installer the "installer toolbox."
As Chuck has mentioned, that cygwin1.dll should have a different shared
memory region identifier, to prevent crashes :}.
> The ash shell that would be run by RPM for the post-install and
> pre-uninstall scripts would be the installer toolbox version, not the
> one in the installation directory, nominally C:\Cygwin\bin\ash.exe.
ok... how do you update that installer toolbox?
> Robert> 1) consider an ash script run when updating ash?
> OK, I think there are two cases to consider: installing the packages
> with Tcl/Tk GUI installer, and installing packages by hand using RPM
> directly on the command line. In the first case, the installer
> toolbox is available, and this version of ash is the one that runs the
> RPM package scripts. Keep in mind, DLL conflicts will be avoided by
> verifying this in the first stage of the install. So, ash should run
> fine. In the second case, yes, running an RPM script when updating
> ash could be a problem. However, the current RPM ash package I've
> build doesn't have any post-install or pre-uninstall scripts, so it's
> not a problem. In the case that future ash RPMs require installer
> scripts, we just make sure these are put into a separate sub-package,
> so we know that we always have a valid ash to run RPM installer scripts.
> Robert> 2) Consider other scripts running when updating ash?
> The only way I see this being a problem is if . If it's any
> consolation, this same problem in theory should affect the Linux
> version of RPM as well, so we're no worse off.
Unix allows the deletion and replacement of open files, win32 doesn't.
Thats the root of the problems I'm highlighting - so no, Linux is not as
badly off as we are :}.
> Robert> 3) Consider rpm updating itself ?
> This shouldn't be a problem. The way I think it should be handled is
> that version updates to RPM should be handled by the installer anyway,
> and the installer has its own "installer toolbox" version of RPM.
> This should avoid conflicts with the installed version of RPM.
Again, how do the users update the toolbox? Or do they download a 5mb
install for the toolbox when it needs updating?
> Robert> IMO, the setup program should update cygwin1.dll; force a
> Robert> reboot if needed to get the new dll copied in (MS document
> Robert> how to do this); then call into cygwin linked programs to
> Robert> do the real work (including rpm).
> I mean no disrespect to your comments, but I really dislike rebooting
> *any* machine (even NT machines :-)), both as a programmer and as a
> user. Besides, there's no *need* to reboot, if we can impose slightly
> on the user.
I dislike the idea too :}. I also dislike many other things about win32
> Here's what should happen: the first stage installer detects a Cygwin
> DLL conflict, and determines which currently running application(s)
> have links to cygwin1.dll. We present this list to the user, saying
> "we've noticed the following Cygwin app(s) are running. Before you
> can continue with the installation, please close these apps down.
> Re-run the installer after you've done this." By asking the user to
> shut down the apps, we accomplish two things: cygwin1.dll gets
> unloaded, and we avoid the reboot.
Uhmm, assuming the user actually knows whats going on. Consider a user
that is not the sysadmin of the machine, and doesn't know that sshd is
running. In theory, yes with user cooperation, you can do this. In
practice I suspect that saying "we have installed a new version of
cygwin1.dll, to make it take effect reboot your machine" will be less
prone to support questions.
> 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...
> I very much aspire to the design philosophy of Antoine de
> "You know you've achieved perfection in design,
> Not when you have nothing more to add,
> But when you have nothing more to take away."
> This "replace file on reboot" feature would be a special case just to
> accomodate the installer, and not a generally useful feature, IMO, for
> porting general POSIX apps to Win32. Besides, I think the approach
> I've outlined above would work just fine, and would avoid adding any
> unnecessary feature (i.e. not needed by a range of POSIX apps) to the
> Cygwin DLL.
Weeeel, what would be really nice would be a hack to cygwin's
delete-on-close queue, to allow the unix "delete this open file, now
write a new file with the same name" functionality, with cygwin setting
up a replace-on-reboot, and removing that replace-on-reboot if/when the
file is actually closed and able to be done manually. _And_ for cygwin
linked process, redirecting any opens to the queued replacement file :}.
That way the posix semantics would be present, for most files. However
such a hack could be very difficult to do _the right way_... and I'm not
going to get sidetracked by it :].
> BTW, great comments, I really appreciate the time you took to analyze
> the RPM installer design. Thanks!
Thank you. The developer list has spent a bunch of time tossing around
various ideas - that was a synopsis of the critical issues that any
cygwin hosted installer has to overcome. (Note that cygwin used to have
a cygwin-hosted installer, and moved away from that post B20.1).
> Dario Alcocer -- Sr. Software Developer, Helix Digital Inc.
> email@example.com -- http://www.helixdigital.com
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html