[92462] trunk/dports/databases

[Ryan Schmidt]

On Apr 29, 2012, at 02:57, vince at macports.org wrote:

> Revision: 92462
>          https://trac.macports.org/changeset/92462
> Author:   vince at macports.org
> Date:     2012-04-29 00:56:57 -0700 (Sun, 29 Apr 2012)
> Log Message:
> -----------
> Initial commit
> 
> Added Paths:
> -----------
>    trunk/dports/databases/postgis2/
>    trunk/dports/databases/postgis2/Portfile
>    trunk/dports/databases/postgis2/files/
>    trunk/dports/databases/postgis2/files/ed_commnd
> 
> Added: trunk/dports/databases/postgis2/Portfile

> +revision            9656
> +version             2.0.1-svn

> +fetch.type          svn
> +svn.revision        ${revision}
> +svn.url             http://svn.osgeo.org/postgis/trunk

I guess you don't need to change it now...

but it's generally a mistake to set revision and svn.revision to the same value. They're different variables; they serve different purposes.

Also, "svn" should not appear the version line. If this is the development line that will eventually become 2.0.1, you could have called it 2.0.0.90 perhaps, that way you could have later upgraded the port to the real 2.0.1 easily. Or if you don't want to invent upstream version numbers, you could have called it 2.0.0-YYYYMMDD where YYYYMMDD is the date of the subversion revision you're checking out. You could also call it 2.0.1-YYYYMMDD, but in order to then get to the 2.0.1 final version, the epoch will need to be increased. But the epoch will already need to be increased anyway when you want to move from "2.0.1-svn" to "2.0.1", to counteract this:

$ ~/macports/users/ryandesign/scripts/vercmp 2.0.1-svn 2.0.1
MacPorts considers 2.0.1-svn to be greater than 2.0.1.


> +pre-fetch {
> +    if {[join [split [exec ${prefix}/bin/geos-config --version] "."] ""] < 332\
> +        && [variant_isset topology]} {
> +        
> +        return -code error  "Topology module requires at least geos 3.3.2.\
> +                            Please upgrade."
> +    }

MacPorts automatically upgrades dependencies for you, so this kind of checking is not necessary in individual ports. Furthermore, a user who does not have geos installed will encounter an error message if they try to just run "sudo port fetch postgis2" (as opposed to "sudo port install postgis2") because the geos-config program won't exist:

$ sudo port fetch postgis2
--->  Computing dependencies for postgis2
--->  Fetching distfiles for postgis2
Error: org.macports.fetch for port postgis2 returned: couldn't execute "/opt/local/bin/geos-config": no such file or directory
Please see the log file for port postgis2 for details:
    /opt/local/var/macports/logs/_Users_rschmidt_macports_dports_databases_postgis2/postgis2/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port postgis2 failed

So I suggest you just remove these lines.


> +    # Can’t install a non-universal PostGIS on a universal PostGreSQL
> +    if {![catch {exec ${prefix}/bin/port installed $PGVERSION\
> +                    |& grep universal}] && ![variant_isset universal]} {
> +        
> +        return -code error  "Since $PGVERSION has been built universal,\
> +                            PostGIS must also be built universal."
> +    }

For the same reason, this check should occur at pre-configure time, because at pre-fetch time, the dependencies have not necessarily been installed yet.

Anyway, shelling out to "port installed" and "grep" is pretty messy; there are better ways to ask MacPorts to query its registry of installed ports.