On 10/10/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
> > If it doesn't need to be in core, in certainly has zero need to be in
> > contrib and can push to pgFoundry.
>
> One advantage of having it in contrib is buildfarm testing, as indeed we
> already found out ... although it's true that *keeping* it there now
> that it passes probably won't teach us too much more.
>
> But I think the argument that was being made was mostly that the Slony
> and Skytools projects would find it easier to depend on a contrib module
> than on something that has to be fetched separately from pgfoundry.
> Now they could work around that by including copies of the pgfoundry
> project in their own distributions, but then they have a collision
> problem if someone tries to install both together. (I have no idea how
> likely that is, though; it might not be a big problem in practice?)
Well, if it is kicked from /contrib now, one way we could handle
it is by shipping the same module inside both skytools/slony.
That has obvious conflict problems.
Unfortunately the problem has very easy fix - each one keeps
using it's current module. Very easy, no work required.
But that also scratches the common API possibility.
--
marko
