This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)
>>>>> "Chuck" == Charles Wilson <cwilson@ece.gatech.edu> writes:
Chuck> **IF** you're going to pursue this, The Right Way(tm) is to
Chuck> build a special cygwin1.dll AND import lib environment,
Chuck> where the "shared memory region name" is different -- and
Chuck> perhaps the dll name itself, as well. Also, it should use
Chuck> a different registry key for mounts and such,
Chuck> probably. (Check the cygwin archives wrt. error_start and
Chuck> gdb for some info on how to do the "shared memory region
Chuck> name" thing). Then, build your special ash and rpm and db
Chuck> and utils within that environment (you may need to also
Chuck> build gcc?)
Chuck> Okay, so no2 you've got a nice, self-contained
Chuck> "cygwin"-based mini-environment that will not interfere
Chuck> with a "real" cygwin environment. So, the mini-environment
Chuck> should be able to update anything in the real environment,
Chuck> with the usual caveats about files in-use by "real" cygwin
Chuck> programs.
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
Please let me know what you think regarding this approach.
--
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/