Projects that are as organized, professional, and value-adding as yours is
can surely stand on their own. I compare this to the recently released
OpenFTS. If we start including projects of this size we'd explode in size
and maintenance overhead.
Doesn't this discussion indicate that
Paul Ramsey <[EMAIL PROTECTED]> writes:
> However, if I have an RPM-based installation, I *will* have
> the server headers I need. Why do we discriminate against people who
> compile from the tarball?
We don't. We do, however, assume that they read the installation
instructions:
The standa
I would take a hard look at R's extension packaging system
(www.r-project.org). Its the best in the business. It consolidates all
aspects of creating packages, including configuring, building, run-time
linking, documentation and testing. It also allows non-root users to
install packages in
Brook Milligan writes:
> Doesn't this discussion indicate that the time is fast approaching, if
> not already past, for some type of system for handling installation of
> 3rd party software?
Yes.
> - Definition and implementation of the interface to be provided for
> extensions. Presumably,
Peter Eisentraut wrote:
> The 7.1 RPMs should contain the server side headers somewhere. Earlier
> versions only included a not very well defined subset of them.
Indeed they do (nice!), which brings me to a different question:
1 - I download the tarball
2 - ./configure ; make ; make install
Paul Ramsey writes:
> - One of the things we have run up against is that for most linux
> distributions, the postgresql-devel package does not include postgres.h
> in the header package. This is not necessary for client-side programs,
> but it is for server-side extensions. So people cannot compi
Peter Eisentraut wrote:
> Projects that are as organized, professional, and value-adding as yours is
> can surely stand on their own. I compare this to the recently released
> OpenFTS. If we start including projects of this size we'd explode in size
> and maintenance overhead.
Fair enough... p
Paul Ramsey writes:
> Perhaps we could back up at this point and revisit 'contrib' ... at what
> point in the size/licence/redundace spectrum do we become reasonable
> candidates for 'contrib', if ever? The current tenor seems to be that at
> 600K/GPL/point-line-polygon we are "too big"/"too rest
Dave Blasby wrote:
>
> The next question is, of course, what does 'semi-compliant' mean? Or,
> more interesting, why would you want a semi-compliant database? For
> most people's simple tasks, the built in geometry types are adequate.
> Those interested in doing more complex tasks will probably
Tom Lane wrote:
>
> Dave Blasby <[EMAIL PROTECTED]> writes:
> > [snip] Vivid Solutions (cf.
> > http://www.vividsolutions.com/jts/jtshome.htm) will be releasing it
> > under the LGPL.
> > [snip]
> > This leaves the option for creating a semi-compliant OpenGIS core inside
> > PostgreSQL and having
Dave Blasby <[EMAIL PROTECTED]> writes:
> [snip] Vivid Solutions (cf.
> http://www.vividsolutions.com/jts/jtshome.htm) will be releasing it
> under the LGPL.
> [snip]
> This leaves the option for creating a semi-compliant OpenGIS core inside
> PostgreSQL and having a LGPL add-on for the complex sp
I think it would be great for PostgreSQL to be an 'OpenGIS Simple
Feature Specification for SQL' compliant database with robust spatial
operators right-out-of-the-box.
Currently, PostGIS implements most of the OpenGIS specification. The
unimplemented portions are the important; spatial operator
12 matches
Mail list logo
