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: <3B60C7B2.220A8A5B@ece.gatech.edu> Date: Thu, 26 Jul 2001 21:45:22 -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: Dario Alcocer CC: cygwin AT cygwin DOT com 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> <3B5F5731 DOT 1090000 AT ece DOT gatech DOT edu> <15200 DOT 14597 DOT 953781 DOT 596499 AT coyote DOT priv DOT helixdigital DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dario Alcocer wrote: > Chuck> The difficulty here is you've got to maintain TWO separate > Chuck> binaries for your core utilities -- one set of (cygwin > Chuck> itself, ash, rpm, db, etc) for the "real" system and one > Chuck> set for the "mini" environment. > > I think this would be the major sticking point; having a parallel > set of Cygwin binaries would be problematic, both for maintenance and > support. > > I think the approach I've outlined in the following message should > work: > > http://www.cygwin.com/ml/cygwin/2001-07/msg01508.html Ummm...in that message you DO talk about an "'installer-toolbox' version of RPM". I just like making things explicit: remember that executables embed the filename of the DLLs on which they depend. So, if your "ITK" cygwin dll was named cygwin1.dll, then sure: you could use the same rpm.exe both in the ITK and "for real". But then, you're deliberately installing two different cygwin1.dll's on a system (even temporarily -- but what about people who like to keep the ITK around?). AND you have to play games with $PATH so that the "right" one is used in the proper circumstances. Sure, in THIS case the two dll's will not cause the problems we've all grown to know and love, since they have different shared region names. But how do you explain that to your users? "But I asked on the cygwin list and they said never have two cgywin1.dll's. So I deleted the one with the newer timestamp from C:\cygwin\bin and left the one in \cygwin-itk\" Geez. What a nightmare. It seems easier (from a long-term, customer-support perspective) to build the the ITK-cygwin dll with a different name (say, cygwin1-itk.dll) and then link special versions of your ITK progs against it. So, you'd have: cygwin1-itk rpm-itk ash-itk textutils-itk tcl/tk-itk And that's probably it. (Now that I think about it, you probably don't need a special gcc for building the itk tools -- just swap two different spec files...) Sure, short term this looks like hell. But "The Right Way To Do Things(tm)" usually does. And is usually better in the long run. --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/