Blanket approval to modernize the Ports Tree
freebsd at grem.de
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 FreeBSD.org>
> 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 , 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
 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
More information about the freebsd-ports