This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]