Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <3B60C50B.237E8DF5@ece.gatech.edu> Date: Thu, 26 Jul 2001 21:34:03 -0400 From: Charles Wilson X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: cygwin AT cygwin DOT com CC: Dario Alcocer Subject: Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86) 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> <996191259 DOT 22763 DOT 10 DOT camel AT lifelesswks> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert Collins wrote: > ok... how do you update that installer toolbox? As Dario said, you don't. I just wanted to point out how pkgconfig and glib-1.3 handle this. I recently discovered (during my unsuccessful attempts to build glib-1.3 using "new-style" tools (see recent postings on binutils, automake, and libtool lists)) that recent gnome stuff like glib-1.3.x no longer use the assortment of "*-config" scripts. Instead, they require a separate tool, called "pkg-config". Okay, but pkg-config depends on glib, and glib depends on pkg-config. so what they do, is ship an old, stable version of glib WITH the pkg-config source. pkg-config then automatically builds and links ONLY to its included copy of glib-1.2.10. (Side benefit: glib-1.2.10 is MUCH smaller and simpler than glib-1.3.x. Some *major* code bloat going on there, IMO...) So, Dario's RPM-based install kit can ship with a nice stable cygwin1.dll (taking care to provide the source for THAT version, so the GPL is happy). Now, I'm not suggesting that he use 1.1.8 or (heaven forbid) that he "strip down" to a special reduced-functionality "kernel" like pkg-config does, but 1.3.2 is pretty good. If ALL that is being used in the install kit is RPM and sh, and perhaps awk and sed, it's unlikely that those will tickle any serious bugs in this "old" version. His install kit can stay at 1.3.2 "forever" -- or until HE decides that he needs to upgrade it. His end users needn't worry about it. > > 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. Hmmm...if I run "ps" with a special cygwin1.dll that has a different shared region name, will it see processes being run with the "real" cygwin1.dll? (I'd imagine so, but I haven't tried it myself, so I'm not sure). > 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. Yeah, but we say "shut down all running cygwin applications before running setup.exe" How is our method any different than Dario's proposed version? (Actually, his is better because he says "Hey luser: you've still got X and Y and Z cygwin-based programs running. Shut 'em down" --Chuck -- 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/