[MacPorts] #16238: Port for MapServer

[MacPorts]

#16238: Port for MapServer
--------------------------------------+-------------------------------------
  Reporter:  mbarchfe at googlemail.com  |       Owner:  macports-tickets at lists.macosforge.org
      Type:  enhancement              |      Status:  new                                  
  Priority:  Normal                   |   Milestone:  Port Submissions                     
 Component:  ports                    |     Version:  1.6.0                                
Resolution:                           |    Keywords:                                       
--------------------------------------+-------------------------------------
Comment (by mbarchfe at googlemail.com):

 > > > we don't have a category "gis". Perhaps the port would fit into one
 of the existing categories.
 > > Where can I find out about valid categories? According to
 http://www.macports.org/ports.php ther is a gis category.
 > Oh, I see, indeed ports.php does show a gis category. I was going by
 "`port lint`" which said the category didn't exist. lint currently goes
 off a list that's in [browser:trunk/base/src/port1.0/portlint.tcl
 portlint.tcl], while I believe ports.php gathers all categories of all
 ports and displays them. Looks like only the spatialite port currently
 claims to be in category gis. Would the science category be appropriate?
 That's where ports like gdal, geos and proj are currently filed. Or if it
 would help people to find the software if the ports were in a category
 gis, we could officially add that category. Ports can be in multiple
 categories; e.g. you could file them in science and gis.
 I think it would make sense to add the gis category.
 gdal/geos/proj/grass/mapserver/gdal-grass should probably be tagged for
 the science and gis category.
 >
 > > >  * You don't wish to be the maintainer of this port?
 > > Actually I hoped I could throw this over the fence and get away with
 it ;-). But if being the maintainer means I can directly submit changes to
 the Portfile that would be fine with me.
 > You don't need to be maintainer if you don't want to. :-) The problem is
 that ports with no mainatiner seem to bitrot as nobody feels responsible
 for them, and already 46% of our ports have no maintainer. By being a
 port's maintainer, you're saying that you will keep it updated and be a
 point of contact for users having questions about the MacPorts-specific
 aspects of the software. You would still need to file tickets to effect
 those updates, unless you want to
 [http://guide.macports.org/#project.membership request commit access to
 the repository].
 Then I would suggest that you enter my email address as maintainer and add
 the ports to the repository. I will then request access to the repository.
 >
 > > >  * It looks like the variant "wms" doesn't do anything so it should
 be removed.
 > > It adds a necessary dependency for wms. I wanted this category just to
 make it explicit.
 > But the wms variant doesn't do anything. It only contains the comment
 "--with-wms is enabled by default". The description of the variant reads
 "Enable Web Map Service" but that's not what the variant does. Regardless
 of whether I install mapserver +proj or mapserver +proj +wms I get exactly
 the same software which has wms enabled. So the wms variant should go
 away. If there is value in allowing wms to be disabled, then you could add
 a variant no_wms which appends the configure argument `--without-wms`. Is
 there a reason why anyone would want to disable wms?
 No, but wms depends on proj and if somebody wanted to enable wms (s)he
 would have to add the proj variant. --with-wms is given per default but
 will only be considered if there is proj support as well. Since I did not
 regard this as intuitive I have added the wms variant. As an alternative
 the proj variant could be renamed to wmsproj or so.

-- 
Ticket URL: <http://trac.macports.org/ticket/16238#comment:7>
MacPorts <http://www.macports.org/>
Ports system for Mac OS