FreeBSD port of CONNECT BY patch for pgsql
John Nielsen
john at jnielsen.net
Wed Mar 16 09:24:35 PST 2005
On Wednesday 16 March 2005 07:16 am, you wrote:
> --On tisdag, mars 15, 2005 22.38.33 -0700 John Nielsen
> <john at jnielsen.net> 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
More information about the freebsd-ports
mailing list