From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5869 invoked by alias); 9 Nov 2008 21:21:30 -0000 Received: (qmail 5810 invoked by uid 22791); 9 Nov 2008 21:21:29 -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; Sun, 09 Nov 2008 21:20:30 +0000 Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id BEEC71AD851 for ; Sun, 9 Nov 2008 16:20:27 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 09 Nov 2008 16:20:27 -0500 Received: from [192.168.1.3] (user-0cej09l.cable.mindspring.com [24.233.129.53]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4734F35EFC; Sun, 9 Nov 2008 16:20:27 -0500 (EST) Message-ID: <49175419.5020409@cwilson.fastmail.fm> Date: Sun, 09 Nov 2008 21:21: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> In-Reply-To: <49168071.3050405@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/msg00061.txt.bz2 Yaakov (Cygwin Ports) wrote: > Charles Wilson wrote: >> a) my example, ncurses, has a LOT (50 or so) "official" patches >> b) they are all gz-compressed; cygport might not support compressed >> patches in PATCH_URI > > Compressed single patches are supported in PATCH_URI since 0.3.5. Good to know. I /thought/ that was the case, but was too lazy to check while composing the email. >> So, in fact, for ncurses (where some of the official upstream "patches" >> are actually shell scripts with shar-compressed patches!) I actually >> DON'T specify these files in PATCH_URI. Instead, I specify them in >> SRC_URI, and then use src_unpack_hook to apply (that is, execute!) them. > > Interesting, I'd like to see those "patches"; with the recent release of > ncurses-5.7, all the 5.6 patches are gone. 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/ > I think you know that I haven't been a big fan of this idea. > Nevertheless, cygport 0.9.x allows you to call src_compile(), > src_install(), or any self-defined function on the command line, but it > doesn't allow for any arguments to the function. Adding that limitation > made the implementation much easier than what you were proposing, and I > hope that it will be sufficient. Yes, that will do. If one really needs to pass arguments -- which I (usually) don't -- there are a number of workarounds: 1. export MY_FUNC_ARGS=("a b" c "d e"); cygport foo.cygport my_func where my_func() processes MY_FUNC_ARGS[@] (which in this case has three elements, "a b", c, and "d e"). 2. You could do something similar with response files 3. Reduce granularity and then have a few specific functions. For instance, rather than: cygport cvs.cygport custom1-run_test N where N is any number from 1 to 300, instead do cygport cvs.cygport run_test_group1 cygport cvs.cygport run_test_group2 cygport cvs.cygport run_test_group3 cygport cvs.cygport run_test_group4 where each group comprises 75 or so tests. I'd probably lean to #1. If it ever came up. In any event, all of those workarounds can be implemented solely inside a specific .cygport file, without any additional (or intrusive, or ugly-as-sin) changes to /usr/bin/cygport. The custom- stuff is a marvelous (ab)use of bash, though, ain't it? That leaves only: cvs topdir support postinst hook support relocatable [*] ===== [*] relocatable. I've ported those changes to 0.4.2, but...they are really, just, wow. Awesomely ugly. I've decided to drop them entirely, for the following reasons: 1) According to Bruno, "official" packages aren't supposed to be relocatable. "I hope that people will learn when to use --enable-relocatable by themselves. For example, I don't think a Linux distributor should use --enable-relocatable for anything installed in /usr - it would only be bloat that makes the system slower." Since the relocatable magic applies only to libintl, gettext, (and my personal patched versions of proj and libgeotiff) -- all of which I maintain and which go into cygwin's /usr -- Bruno's argument against --enable-relocatable applies. 2) cygport is intended for use in packaging "official" cygwin stuff. Not random compiled-with-wierd-options stuff. So, it doesn't really need to support the rather esoteric --enable-relocatable, as official packages aren't supposed to use that option (see 1). 3) --enable-relocatable is a bad fit for cygport. As a consequence of cygport's focus on "official packages only", it always installs into /usr. It's sorta hard to force it into installing to /tmp/cygport-reloc-au723g/ -- the whole --enable-relocatable scheme relies on using such odd, random, never-repeated, --prefixes. 4) The only reason I was even bothering was to help iron out the bugs in Bruno's reloc support. Well, as of 0.17, it needed almost ZERO additional effort from me to make it work (a single two-line patch -- and THAT was actually gnulib's fault, not Bruno's reloc stuff). I think that qualifies as "good enough" and I can, in the future, test reloc support "normally" -- that is, configure/make/install sans-cygport. 5) Ye GODS, the patch is ugly. I'll post it for historical interest, but...yuck! ===== FWIW, here's the current ncurses prep function (eventually to become src_unpack_hook when I release 5.7). ${PF}.extra.patch is a separate patch (of mine) that I wanted to keep separate from .src.patch. SRC_URI="mirror://gnu/ncurses/${PN}-${PV}.tar.gz \ ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20060909-patch.sh.bz2 \ ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20060916.patch.gz \ ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20060923.patch.gz \ ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20060930.patch.gz \ ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20061007.patch.gz \ ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20061014.patch.gz \ ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20061021.patch.gz \ ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20061028.patch.gz \ ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20061104.patch.gz \ ${PF}.extra.patch" src_prep_init_hook() { local -i n=1 local -a mySrcURI=($SRC_URI) local breakout="" local pnz local pn local msg cd ${origsrcdir}/${SRC_DIR} # This "loop" is only executed once (at most). We # use 'while' instead of 'if' because it is a more # flexible control flow structure. while [ ${n} -lt ${#mySrcURI[*]} -a -z "${breakout}" ] do breakout="yes" pnz=${mySrcURI[${n}]##*/} case "${pnz}" in *.gz ) pn=${pnz%.gz} ;; *.bz2 ) pn=${pnz%.bz2} ;; * ) pn=${pnz} ;; esac case "${pn}" in *.sh ) n+=1 ;; * ) continue ;; esac if [ -f ${origsrcdir}/${pn} ] then inform "APPLYING OFFICIAL ROLLUP PATCH: ${pn}" ${origsrcdir}/${pn} else if [ -f ${origsrcdir}/${SRC_DIR}/${pn} ] then inform "APPLYING OFFICIAL ROLLUP PATCH: ${pn}" ${origsrcdir}/${SRC_DIR}/${pn} else warning "COULD NOT FIND OFFICIAL ROLLUP PATCH: ${pn}" fi fi done while [ ${n} -lt ${#mySrcURI[*]} ] do pnz=${mySrcURI[${n}]##*/} msg="OFFICIAL INCREMENTAL PATCH" case "${pnz}" in *.gz ) pn=${pnz%.gz} ;; *.bz2 ) pn=${pnz%.bz2} ;; *.patch ) pn=${pnz} ; msg="CYGWIN SPECIAL PATCH" ;; * ) warning "Skipping unknown file: ${pnz}" n+=1 continue ;; esac if [ -f ${origsrcdir}/${pn} ] then inform "APPLYING ${msg}: ${pn}" apply_patch ${origsrcdir}/${pn} else if [ -f ${origsrcdir}/${SRC_DIR}/${pn} ] then inform "APPLYING ${msg}: ${pn}" apply_patch ${origsrcdir}/${SRC_DIR}/${pn} else warning "COULD NOT FIND ${msg}: ${pn}" fi fi n+=1 done } -- Chuck