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