Blanket approval to modernize the Ports Tree

Michael Gmelin freebsd at
Tue Jan 7 10:21:01 UTC 2014

On Tue, 7 Jan 2014 00:06:56 +0000
FreeBSD Ports Management Team Secretary <portmgr-secretary at>

> In years gone by, and I am thinking of FreeBSD 7.0 specifically,
> portmgr@ gave some latitude to *ALL* committers to "just fix things"
> to get a port into shape.  In the case of 7.0, it was making ports
> build for gcc4.
> What we have laying ahead of us is a ports tree in various states of
> modern preparedness (new style USES=, stagefication, etc) and the old
> way of doing ports (boo!).
> We would like committers, and contributors to generate a PR and/or
> "just fix" the old ports to update them to the new way of doing
> things regardless of maintainership.  We are looking for fixes in the
> following areas
> - Convert to LIB_DEPENDS
> - stagify ports
> - convert things like USE_GMAKE -> USES=gmake USE_DOS2unix ->
> USES=dos2unix etc.
> This can be done with implicit portmgr@ blanket approval, and without
> maintainer approval.
> Please, however, respect some boundaries, do not change ports
> belonging to kde@, gnome@ or x11 at .  These teams work in private repos
> that may have changes pending.
> Also, cross reference GNATS, to see if a port has an open PR that you
> can factor into the fix.  It is important to stress here that we *DO
> NOT* want to invalidate existing patches that a maintainer has
> offered up or already approved.
> If the change is very trivial AND has been tested, "just fix it".
> One of the strengths of the Ports Collection is it's volunteer
> maintainers, if you make a change, regardless of how trivial, just
> send a courtesy email to the maintainer.

In the light of this blanket approval, could you please take a look at

It's a maintainer update for three ports that I submitted a month ago,
which among other things brings support for 10-RELEASE [1], staging and

It also converts those closely related ports to a master/slave

It doesn't do the USES conversion, but that should be fairly trivial
for the committer working on it.

I'm of course happy to answer any questions or suggestions for


[1] including a workaround for a problem in FreeBSD 10 which leads to
a different code execution order compared to previous releases of the
OS. It was first reported in July and a fix exists that most annoyingly
hadn't been considered important enough to make it into 10-RELEASE, but
that will be in 10.1. With this workaround it will at least build and
run on 10, see also

Michael Gmelin

More information about the freebsd-ports mailing list