I mean it bring nothing that a regular BUILD_DEPENDS inside the port itself can achieve easily

What is the point about adding this uses?

Fix buildworld

I was thinking about adding a @include in plist to allow this, but this is simpler I do like it.

Address exp-run issues

To be clear, I am validating the content of the file and the principle of a rc.d. Now I am wondering it is won't be better served by a port/package as it has a niche usage anyway (for now at least), and that will make it cover all supported version of FreeBSD straight away.

In D22258#486560, @jhb wrote:

Heh, I had thought about just doing this for the ones used by xtoolchain, but this looks more complete.
One thing that might really be nice would be to have an easy way to have multiple PLIST files so that one could have something like:

PLIST_FILES= ${.CURDIR}/pkg-plist ${.CURDIR}/pkg-plist.${TARGETARCH}

And put "common" files in pkg-plist and ARCH-specific files in the sub-plists rather than duplicating lots of plist content. For freebsd6-gcc I used a unified plist with PLIST_SUB's for ARCH-specific files, but having a nice way to have pkg-plist.${FOO} in addition to pkg-plist would be nicer IMO.

Address @mat points

I was about to commit the same change.

at quick glance It looks like it should more be a bunch of flavors than slave ports, am I missing something?

did you forget that one?

Thinking more about it and considering the imminence of the 2.5 release I think we should in that case to even more changes.

yes sasl is used by many end users, as far as I know from personal experience and also from end user reports, SASL is required to be able to properly used the client in most corporate setup including interacting with Active Directory.

I do think it is too short for a USES, I can do it, but in this case it seems simpler like this to me.

Note that the same patch was provided by @naito.yuichiro_gmail.com in D21584 (and he contacted upstream for it to be committed in.) Please mention him also in the commit log