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
Subject: RE: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)
From: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
To: Dario Alcocer <alcocer AT helixdigital DOT com>
Cc: cygwin AT cygwin DOT com, Bernard Dautrevaux <Dautrevaux AT microprocess DOT com>
In-Reply-To: <15200.14214.419912.961927@coyote.priv.helixdigital.com>
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>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.11 (Beta Release)
Date: 27 Jul 2001 09:47:35 +1000
Message-Id: <996191259.22763.10.camel@lifelesswks>
Mime-Version: 1.0
X-OriginalArrivalTime: 26 Jul 2001 23:33:54.0529 (UTC) FILETIME=[6F081510:01C1162B]

On 26 Jul 2001 08:30:14 -0700, Dario Alcocer wrote:
> >>>>> "Robert" == Robert Collins <robert DOT collins AT itdomain DOT com DOT au> writes:
> 
>     Robert> On 25 Jul 2001 14:08:02 -0700, Dario Alcocer wrote:
> 
>     >> >>>>> "Bernard" == Bernard Dautrevaux
>     >> <Dautrevaux AT microprocess DOT 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
> Saint-Exupery:
> 
>     "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).

Rob

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