From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7423 invoked by alias); 10 Nov 2008 02:47:21 -0000 Received: (qmail 7220 invoked by uid 22791); 10 Nov 2008 02:47:20 -0000 X-Spam-Check-By: sourceware.org Received: from out5.smtp.messagingengine.com (HELO out5.smtp.messagingengine.com) (66.111.4.29) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Nov 2008 02:46:22 +0000 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 77EDB1AB00D for ; Sun, 9 Nov 2008 21:46:20 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sun, 09 Nov 2008 21:46:20 -0500 Received: from [192.168.1.3] (user-0cej09l.cable.mindspring.com [24.233.129.53]) by mail.messagingengine.com (Postfix) with ESMTPSA id E840536EE1; Sun, 9 Nov 2008 21:46:19 -0500 (EST) Message-ID: <4917A078.9090200@cwilson.fastmail.fm> Date: Mon, 10 Nov 2008 02:47:00 -0000 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.17) Gecko/20080914 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Mailing List: CygWin-Apps Subject: Re: cygport-0.9.3 in release-2 References: <4906B2F8.4000708@users.sourceforge.net> <747eg4dsfpl4befpo8gb4qkgo3sm0d8fbi@4ax.com> <747eg4dsfpl4befpo8gb4qkgo3sm0d8fbi-e09XROE/p8c@public.gmane.org> <4907C0F1.2040005@cwilson.fastmail.fm> <4914ED2E.3000106@cwilson.fastmail.fm> <49168071.3050405@users.sourceforge.net> <49175419.5020409@cwilson.fastmail.fm> <4917790A.8040400@users.sourceforge.net> In-Reply-To: <4917790A.8040400@users.sourceforge.net> 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-11/txt/msg00063.txt.bz2 Yaakov (Cygwin Ports) wrote: >> They were called "rollup" patches. T.E.D. releases patches roughly every >> week, and then every month (or two, or three), he combines all patches >> dating back to an official release into a "rollup" patch -- and these >> "rollup" patches are in the shar-archive-auto-apply format. You can see >> an example in the current cygwin ncurses-5.5 package (yes, two years >> old. I know...) T.E.D. also provides the patches to update a 5.x tree >> to 5.x+1 in that form: > >> ftp://invisible-island.net/ncurses/patches/ > > Looking at 5.5-3, all those patches can be in PATCH_URI instead. Even the "rollup" patch? ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20060909-patch.sh.bz2 >> That leaves only: >> cvs topdir support >> postinst hook support > > cvs topdir: this has little benefit and would break ABI. It only breaks the ABI (B?) if you do it the way you suggested: http://cygwin.com/ml/cygwin/2008-05/msg00038.html > I suppose a cleaner solution would have been to add a '-d > ${CVS_MODULE##*/}' to the checkout command, but doing that now would > break existing -src packages. Anyway, that wouldn't actually work either. Modules aren't necessarily directory names. For instance, take the binutils module: binutils -a naked-binutils naked-opcodes naked-bfd naked-libiberty \ naked-include naked-gas naked-gprof naked-ld naked-gold \ naked-elfcpp naked-intl src-support naked-texinfo naked-cpu If I wanted to checkout the 'naked-binutils' module, in /THAT/ case I would really expect to get src/binutils/ and would be annoyed to get naked-binutils/ There's really no "rule" like '-d ${CVS_MODULE##*/}' that is universally applicable: the module name and the -d option (if present) are orthogonal controls. You don't want to tie them together. The way my patch does it, there is no API breakage -- but you have a new API entry point [the new CVS_DIR variable]. The price of API preservation is a proliferation of new ones; just ask Bill Gates. The benefit of allowing some mechanism to pass a -d option to the cvs checkout is that I can ensure that my cvs.cygclass-generated origsrc tarball has the same directory layout as a make-dist-generated one. But whatever. I'll live with it. Worst case, I'll manually repack the tarball and comment-out the inherit cvs.cygclass. Besides, the only package I know of that has this issue is libgeotiff -- which moved to subversion a few months ago, anyway. So, it's probably moot for all current packages. > postinst hook: RESTRICT="postinst-doc" was supposed to be a workaround. > How was this not sufficient? It is sufficient to override the default behavior of the post-install phase with respect to documentation; that's what the urxvt packages care about. But other packages (unknown at this time, but I'm not possessed of sufficient hubris to rule them out) might need to override/customize some other phase: __src_postinst() { __prep_symlinks; __prepdoc; __prepetc; __prepman; __prepinfo; __prep_empty_dirs; __prepstrip; __prep_libtool_modules; } But I guess you can continue adding new RESTRICT options on an ad-hoc basis. A draw-back to that method is all I can do is STOP the automated system from doing something at the end of the install-phase. The only chance I have to actually DO anything during the install phase is in src_install, which precedes all that. Hopefully there are no, and never will be any, ordering dependencies between the post-install phases; For example: suppose, for some reason, that cygport develops an assumption that __prepinfo MUST always come after __prepman. If I want to do something funky with the info files, all I can do is RESTRICT_postinst-info -- and do my funky thing MUCH earlier, in src_install. So, now, MY "prepinfo" happens before __prepman. But, I suppose there's no sense borrowing trouble; "Sufficient unto the day is the evil thereof". -- Chuck