Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
From:	Dario Alcocer <alcocer AT helixdigital DOT com>
MIME-Version:	1.0
Message-ID:	<15200.14597.953781.596499@coyote.priv.helixdigital.com>
Date:	Thu, 26 Jul 2001 08:36:37 -0700
To:	Charles Wilson <cwilson AT ece DOT gatech DOT edu>
Cc:	cygwin AT cygwin DOT com
Subject:	Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)
In-Reply-To:	<3B5F5731.1090000@ece.gatech.edu>
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>
X-Mailer:	VM 6.76 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid

>>>>> "Chuck" == Charles Wilson <cwilson AT ece DOT gatech DOT 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 AT helixdigital DOT 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/

- Raw text -