From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15548 invoked by alias); 10 Nov 2008 15:25:43 -0000 Received: (qmail 15482 invoked by uid 22791); 10 Nov 2008 15:25:41 -0000 X-Spam-Check-By: sourceware.org Received: from qmta10.westchester.pa.mail.comcast.net (HELO QMTA10.westchester.pa.mail.comcast.net) (76.96.62.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Nov 2008 15:24:56 +0000 Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA10.westchester.pa.mail.comcast.net with comcast id dS2o1a0020mv7h05ATQqoF; Mon, 10 Nov 2008 15:24:50 +0000 Received: from helium ([69.140.155.53]) by OMTA11.westchester.pa.mail.comcast.net with comcast id dTQs1a00j19PpZx3XTQsty; Mon, 10 Nov 2008 15:24:52 +0000 X-Authority-Analysis: v=1.0 c=1 a=hsmAGS6SVkUxu2y57GgA:9 a=a8nSl7x3OUmd6gzJCuIA:7 a=IVWVhfP5nQI8QlJ-UX8-F9z1vZQA:4 a=MxZ3bB5I4kYA:10 Received: from helium ([127.0.0.1] helo=D77E1BASCHULMA1.aa.ad.epa.gov) by helium with smtp (Exim 4.69) (envelope-from ) id 1KzYdI-0001T8-24 for cygwin-apps@cygwin.com; Mon, 10 Nov 2008 10:24:52 -0500 From: Andrew Schulman To: cygwin-apps@cygwin.com Subject: Re: cygport-0.9.3 in release-2 Date: Mon, 10 Nov 2008 15:25:00 -0000 Message-ID: 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> In-Reply-To: <4914ED2E.3000106@cwilson.fastmail.fm> X-Mailer: Forte Agent 4.2/32.1118 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Archive: encrypt 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/msg00067.txt.bz2 > Okay, so these are (mostly) your own custom patches needed to port the > code to cygwin, and not "official" patches from somewhere else Correct. Or anyway, they're patches that aren't included in the source tar= ball, and that I maintain separately as discrete patch files. > Effectively, you're using > src_prep_fini_hook() as a "maintainer mode", and "maintainer mode" is > activated by the presence of ${topdir}/extra/ and ${topdir}/patch/. Exactly. In fact, it's seemed to me for a long time that there was a need = to separate the set of packager/maintainer commands in cygport, from those a u= ser wants if they just want to build the package from source. > $ cygport pkg-VER-2.cygport custom0-import_changeset Sure, this seems fine, if I understand correctly that it runs my custom import_changeset() function. > One advantage of this method is that some other user won't get a > surprising error if they *happen* to have an extra/ directory present > when they try to build your package. They'd have to explicitly invoke > custom0-import_changeset -- and hopefully if they do THAT, then they > know what they are doing. Your way, random files from their extra/ > directory will automatically get copied in, which could be...unexpected. Agreed. > Another advantage -- to my thinking -- is that I *never* import the > original files from extra/ and patch/ unless I explicitly choose to do > so; it won't happen by accident. I think that's good; however, you may > value the "automatic" behavior of embedding this action as part of 'prep'. I always import patches/ and extra/. It's part of my standard build proced= ure. But, it's no big deal to have a separate command for that, if it fits bette= r in the design of cygport. Although... something with a little shorter name th= an custom0-import_changeset would be nice :| > > Note that the problem you mentioned of the patches being applied twice = doesn't > > occur. If I'm building the packages, then the extras/ and patches/ dir= ectories > > are present. Someone else who's building the binary package from sourc= e doesn't > > have those directories >=20 > You hope. No one's complained yet :) > My typical workflow at present involves doing the following after I'm > done with development for a new release: >=20 > <1> > $ cygport foo-VER-REL.cygport pkg > $ tar xvjf foo-VER-REL-src.tar.bz2 > $ cygport foo-VER-REL.cygport finish almostall >=20 > So that I am assured that the distributed src package works. With your > system, you'd have to do >=20 > <2> > $ cygport foo-VER-REL.cygport pkg > $ mkdir temp > $ cd temp > $ tar xvjf ../foo-VER-REL-src.tar.bz2 > $ cygport foo-VER-REL.cygport all > $ mv *.tar.bz2 .. > $ cd .. > $ rmdir temp >=20 > to have the same effect. If you did it as in <1> with your > src_prep_fini_hook, you'd have BOTH the .src.patch and .cygwin.patch > present, AND the extra/ and patch/ directories. That's not an issue with > the extra/ files, but the changes represented by patch/* are duplicated > by the .src.patch changes, and that would definitely bomb out. Well, that is my problem it seems. I generally don't go back and rebuild t= he source package, but when I have I've just moved to a different directory to= do it. > But, having said all that, I realize I'm now just arguing for using a > DIFFERENT non-standard cygport patch. As long as there's some reasonable way to do it, I don't care too much whic= h way it is. Thanks to you and Yaakov for looking at this. Andrew.