From owner-freebsd-ports@FreeBSD.ORG Wed Mar 16 17:24:35 2005 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCCF616A4CE; Wed, 16 Mar 2005 17:24:34 +0000 (GMT) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F42B43D2F; Wed, 16 Mar 2005 17:24:34 +0000 (GMT) (envelope-from john@jnielsen.net) Received: from stealth.local (jn@c-24-2-72-123.client.comcast.net [24.2.72.123]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id j2GHOXVu001055; Wed, 16 Mar 2005 09:24:34 -0800 (PST) (envelope-from john@jnielsen.net) From: John Nielsen To: Palle Girgensohn Date: Wed, 16 Mar 2005 10:26:15 -0700 User-Agent: KMail/1.7.2 References: <200503152238.33442.john@jnielsen.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503161026.16475.john@jnielsen.net> X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on ns1.jnielsen.net X-Virus-Status: Clean cc: ports@freebsd.org Subject: Re: FreeBSD port of CONNECT BY patch for pgsql X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2005 17:24:35 -0000 On Wednesday 16 March 2005 07:16 am, you wrote: > --On tisdag, mars 15, 2005 22.38.33 -0700 John Nielsen > wrote: > > I am interested in creating a FreeBSD port of PostgreSQL 8.0.1 that > > incorporates the CONNECT BY patch found here: > > > > http://gppl.moonbone.ru > > > Second, what would be the best approach in structuring the port? Mr. > > Potemkin distributes his modifications as a single diff against the > > postgres source tree. In addition to needing this file, the port will > > also need to add devel/bison as a build dependency due to the way the > > diff is built and applied (I didn't have bison installed, and had to > > scratch my head for a while on that one). > > OK. Here I see a problem, we have to use a modern enough bison. It seems > that detecting on ${LOCALBASE}/bin/bison-devel is enough? Are you sure > that bison1875 won't work? It does work for unpatched postgresql sources. I should have said "devel/bison-devel" above, since that's what I actually used (and it worked fine). > > I followed this procedure for both the client and the server, since > > they are distinct FreeBSD ports (even though they are both built from > > the same source tree). > > I would imagine that the patches are all for the server, though? Not that > it matters much. It does modify some header files as well, though I > wouldn't know if they are needed for anything outside the backend anyway. > For reasons of simplicity, the client part of the port installs *all* > headers... I included the client just to be safe. If installing an unpatched client before and/or after installing the patched server doesn't break anything then it's just the server I'd woorry abut (I'll test this). > > Would it be possible to do all this as a slave port of the existing > > postgresql80? Would it be better/easier to duplicate the existing port > > and make changes on top of it? > > My suggestion is this: Add an option to the current postgresql80-server > port (something like "use hier patch (EXPERIMENTAL)"). When this option > is checked, add PATCH_SITES and PATCHFILES, and probably an extra > PKGNAMESUFFIX hier. Also, add some blurbs to README files, and perhaps > install en extra README for this (could be practical since it could be > used to differentiate a standard pg install from a pg-hier install, in > case some new port you create would need this functionality). > > Since the patch should probably be considered "experimental", there's > really no need to have a port of its own, IMHO. It seems easier to just > add an optional patch for the normal port? Maybe I'm wrong here? That's an excellent suggestion, and one I hadn't considered. I'll take that approach. > Potential problem is if the hier patchset is not updated fast enough when > postgresql is updated. Good point. I'll get with the author and consider how devoted I'd like to be to this before I submit a PR. > > What would be the best way to apply the patchset within the ports > > framework? As written, the diff needs to be applied from the work > > directory rather than the base of the source distribution directory, > > so I can't just drop it in the port's files directory (can I?). > > patch takes the -p argument, use it with -p1 or perhaps -p2 will fix > this. I'll experiment with that. > > Third, what's the protocol for updating the CONFLICTS of other affected > > ports? > > I'm not sure I understand this question? Check porter's handbook, > CONFLICTS takes normal shell wildcards. What other affected ports would > conflict? Never mind--I didn't think this through all the way. It's especially a non-issue if I just add the patch as an option to the existing port. As for naming, I'll just tack on a 'hier' extension. Thanks. John Nielsen