From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20470 invoked by alias); 20 Aug 2008 16:18:37 -0000 Received: (qmail 20453 invoked by uid 22791); 20 Aug 2008 16:18:36 -0000 X-Spam-Check-By: sourceware.org Received: from out3.smtp.messagingengine.com (HELO out3.smtp.messagingengine.com) (66.111.4.27) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 20 Aug 2008 16:17:50 +0000 Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 4F4A215AA5D for ; Wed, 20 Aug 2008 12:17:48 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 20 Aug 2008 12:17:48 -0400 Received: from [192.168.1.3] (user-0c6suln.cable.mindspring.com [24.110.122.183]) by mail.messagingengine.com (Postfix) with ESMTPSA id B985D2A944; Wed, 20 Aug 2008 12:17:47 -0400 (EDT) Message-ID: <48AC43AA.2000208@cwilson.fastmail.fm> Date: Wed, 20 Aug 2008 16:18:00 -0000 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.16) Gecko/20080708 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Mailing List: CygWin-Apps Subject: Re: New Setup for Cygwin 1.7 on cygwin.com References: <006d01c8fedf$b1fc4040$9601a8c0@CAM.ARTIMI.COM> <20080815141145.GU21040@calimero.vinschen.de> <00fd01c8ff9b$21002310$9601a8c0@CAM.ARTIMI.COM> <20080819164052.GA474@calimero.vinschen.de> <48AB77FC.7C572E74@dessent.net> <20080820024603.GA7287@ednor.casa.cgf.cx> <20080820075751.GD29104@calimero.vinschen.de> <20080820143945.GA8974@ednor.casa.cgf.cx> <20080820144630.GQ29104@calimero.vinschen.de> <20080820151708.GA9193@ednor.casa.cgf.cx> <20080820152546.GR29104@calimero.vinschen.de> In-Reply-To: <20080820152546.GR29104@calimero.vinschen.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com X-SW-Source: 2008-08/txt/msg00185.txt.bz2 Corinna Vinschen wrote: >> I thought the whole point was to install cygwin first. How can you run base >> packages first in a new install when there is no cygwin1.dll? > > The installation order doesn't matter. Only the order in which scripts > run matters. And I don't see another way how to make sure that the > base-* scripts always run first. Well, what we have is a dependency-group. You want cygwin, base-* installed at the same time. Then you want the base-* postinstall scripts to run. Maybe a meta-package? cygwin : no dependencies base-* : depends on cygwin cygwin-meta : depends on cygwin, base-* everything else, that currently depends on cygwin, depends instead on cygwin-meta. ====> revision for less ripple: what we now call the 'cygwin' package gets renamed to 'cygwin-core' base-*: depend on cygwin-core the new 'cygwin' package is now a meta-package with dependencies on cygwin-core and base-*. everything else continues to depend on cygwin, as before. The drawback to this plan is: cygcheck -cd cygwin will report the version number of the meta-package, which will probably be 1.0, and will hardly ever change. This doesn't solve the loop back to cygwin/bash with base-*: base-passwd, setup.hint: requries: cygwin bash NOTE: uses coreutils (cp, rm, chmod) and sed, but does not include them in its requires:. base-files, setup.hint requries: cygwin bash findutils sed NOTE: uses coreutils, diffutils (uname, [, ln, /bin/echo, /bin/touch, /bin/cp, /bin/cmp, /bin/rm ) but does not include them in its requires:. FWIW, does NOT seem to use sed or findutils! bash: requires cygwin libintl8 libreadline6 libintl8: requires cygwin libiconv2 libreadline6: requires cygwin libncurses8 libiconv2: requries cygwin libncurses8: requires cygwin terminfo terminfo: requires bash coreutils NOTE: the only reason this pulls in coreutils is because the postinstall script does this: (cd ${libdir}; rm -f terminfo ; ln -fs ../share/terminfo terminfo ; ) which (a) I need to change to make an absolute link, instead of a relative one, and (b) is it really necessary? Must we have a /usr/lib/terminfo/ path? <--- HERE ---> coreutils: requires bash crypt cygwin libiconv2 libintl8 tzcode crypt: cygwin tzcode: cygwin bash gawk gawk: bash cygwin libintl8 findutils: requires: bash coreutils cygwin libintl8 sed: requires: bash cygwin libintl3 libiconv2 libintl3: requires: cygwin libiconv2 diffutils: requires: bash cygwin libintl2 libiconv2 libintl2: requires: cygwin libiconv2 But I think it would solve the script execution order issue. Also, if we (a) removed terminfo's postinstall script and coreutils dependency (b) removed the useless findutils and sed dependnecy of base-files then the dependency chain of (base-* + cygwin-core == new cygwin meta package) would stop at HERE. This scheme would then rely on the Base category to ensure that coreutils, findutils, diffutils, sed, and all their dependencies are all properly installed, which should be safe enough. Better, in the group above HERE, the following are true; (a) DLL packages don't typically have postinstall scripts (b) terminfo won't have a postinstall script [1] (c) leaving only bash, and base-* postinstall (1) but since bash dep on cygwin (meta), which would dep on cygwin-core (no postinstall), and base-*, but base-* dep on bash... still leaves a cycle. Hmm...what if we deliberatly drop the bash dependency from base-*, relying on the Base category to ensure it gets installed? Then, there are no loops at all (in the cygwin meta group): base-passwd --> cygwin-core <-- base-files ^ ^ ^ \ | / \ | / -----cygwin----- ^ | bash, coreutils, etc... -- Chuck [1] alternatively, if we DO need a /usr/lib/terminfo symlink, then we can keep the postinstall script but deliberately drop the dependency on coreutils (relying on Base category). Then, we still guarantee base-* scripts go first, because terminfo would depend on bash