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

[Dario Alcocer <alcocer at helixdigital dot com>]

>>>>> "Robert" == Robert Collins <robert.collins@itdomain.com.au> writes:

    Robert> On 25 Jul 2001 14:08:02 -0700, Dario Alcocer wrote:

    >> >>>>> "Bernard" == Bernard Dautrevaux
    >> <Dautrevaux@microprocess.com> writes:
    >> 
    Bernard> Or as the installer user interface is tcl/tk-based, you
    Bernard> can look at FreeWrap
    Bernard> (http://home.nycap.rr.com/dlabelle/freewrap/freewrap.html). Its
    Bernard> neat and works quite well; moreover the tcl/tk installer
    Bernard> in this case do not NEED cygwin, so can unpack the basic
    Bernard> bootstrap environment without any problem).

    Dario>  Yes, I guess this would work as well.  However, the main
    Dario> reason I didn't want eliminate the Cygwin DLL was that I wanted
    Dario> to use ash to run the RPM package post-install/pre-uninstall
    Dario> scripts with it.  I guess I could find a Win32
    Dario> Bourne-compatible shell that didn't require Cygwin to replace
    Dario> ash, but that would still leave me looking for Win32-only ports
    Dario> of the other utilities that might be required by the scripts
    Dario> (e.g. awk, sed, cut, paste etc.)

    Dario> In the end, it just seemed simpler that, rather than trying to
    Dario> avoid including Cygwin in the installer (and miss out on all
    Dario> that functionality), I should instead find a way to use
    Dario> cygwin1.dll and avoid the pitfalls instead.  I decided on a
    Dario> two-stage install process; the first stage would check for a
    Dario> duplicate cygwin1.dll loaded in memory (and abort with a
    Dario> message if one was found), and the second stage would be the
    Dario> actual Tcl/Tk installer.

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

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.

    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.

    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.

    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.

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.

    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.

BTW, great comments, I really appreciate the time you took to analyze
the RPM installer design.  Thanks!

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