Allowing more non-maintainer updates

Ryan Schmidt ryandesign at macports.org
Wed Jul 22 13:57:30 PDT 2009


The Non-Maintainer Port Updates section of the guide lists conditions  
when we may update ports that have a maintainer:

http://guide.macports.org/#project.update-policies.nonmaintainer

The existing conditions are:

* The maintainer does not respond within 72 hours
* A port is abandoned by its current maintainer
* A critical port is broken that affects many users

There are some conditions I would like to add to these:

* Required port variable missing (e.g. platforms or long_description)
* Syntax error
* Spelling or grammar error in comments, descriptions, etc.
* Hardcoded /opt/local
* Forgot to bump revision or epoch after change that requires it
* No $Id$ tag
* No svn:keywords or svn:eol-style properties
* Build fix for pre-release Mac OS X version
* Removing code for very old versions of Mac OS X (I would currently  
limit this to Jaguar and earlier; once MacPorts 1.8.0 is released,  
make this Panther and earlier)
* Removing code for ports which will be deleted (e.g. removing mysql3  
variants since I want to remove mysql3 port)

Thoughts? Additions?

I'm thinking about whether we should also allow changes which  
simplify ports, e.g. if a port sets distfiles and worksrcdir but this  
could be changed to just set distname, or if a port uses "system" to  
call some utility but the same could be achieved with a Tcl command,  
or if a port overrides a phase but the same could be accomplished by  
setting phase variables. But I'm not sure how to word it so as not to  
be too ambiguous.

I might also want to allow changes which implement common MacPorts  
idioms, e.g. defining and using a ${branch} variable.



More information about the macports-dev mailing list