It is possible to make it a slave, but we will need to override port version, master site, distfile name, etc.
I would like to do this if this is ever available as a separate patchset, but there is little value in doing so at this point.

FWIW, Percona also distributes pre-patched tarballs, so I think it's reasonable to treat it the same and a server in its own right at this point.

In D9427#194775, @lifanov wrote:

It is possible to make it a slave, but we will need to override port version, master site, distfile name, etc.
I would like to do this if this is ever available as a separate patchset, but there is little value in doing so at this point.

FWIW, Percona also distributes pre-patched tarballs, so I think it's reasonable to treat it the same and a server in its own right at this point.

Given that creating a separate port for each mysql variant seems to be the established practice,
I withdraw my suggestion about slave ports. (But compare the mysql / mariadb / percona ports to the postgresql ports.)

As this is mostly a copy, the port should be created by 'svn cp mysql56-server mysqlwrep56-server' and overwriting with these files, so that there is a connected version history.

Okay, For me only 2 points left.
1- My comments on rc-script and cmake.
2- CONFLICTS part (which needs the naming before it)
The rest seems okay for me.

I'm getting a patch failure on databases/mysqlwsrep56-server/Makefile when I try and do:

% cd ${PORTSDIR}/databases
% svn cp mysql56-server mysqlwsrep56-server 
% arc patch D9427

Looks like mysql56-server has been updated since this differential was prepared.

After fixing the patch so that it would apply (by updating the PORTREVISION setting in the source), I find
that test building on 10.3-RELEASE succeeds but on 11.0-RELEASE it fails due to problems with during configuration:

-- Check size of wint_t - done
-- EDITLINE_INCLUDE_DIR /usr/include/edit/readline
-- EDITLINE_LIBRARY /usr/lib/libedit.so
-- Performing Test EDITLINE_HAVE_HIST_ENTRY
-- Performing Test EDITLINE_HAVE_HIST_ENTRY - Success
-- Performing Test EDITLINE_HAVE_COMPLETION
-- Performing Test EDITLINE_HAVE_COMPLETION - Failed
CMake Error at cmake/readline.cmake:206 (MESSAGE):
  Cannot find system editline libraries.
Call Stack (most recent call first):
  CMakeLists.txt:428 (MYSQL_CHECK_EDITLINE)


-- Configuring incomplete, errors occurred!
See also "/wrkdirs/usr/ports/databases/mysqlwsrep56-server/work/.build/CMakeFiles/CMakeOutput.log".
See also "/wrkdirs/usr/ports/databases/mysqlwsrep56-server/work/.build/CMakeFiles/CMakeError.log".
*** Error code 1

Stop.
make: stopped in /usr/ports/databases/mysqlwsrep56-server
build of databases/mysqlwsrep56-server ended at Sun Feb  5 14:41:35 GMT 2017
build time: 00:01:42
!!! build failure encountered !!!

In Galera land, a node can do one of two things when starting up: join a cluster (start) or create a cluster (bootstrap).
So, you can't bootstrap a node before starting it. If you bootstrap a node automatically if a start times out, you ensure confusion and data loss.

When a node starts, it starts in a desynced state and looks at a variable which is a combination of endpoints to download cluster state from. The first node to start up doesn't have anywhere authoritative to download the cluster state, so bootstrap instructs it to ignore this step and create a new cluster with just itself as a member.

Historically, this was done by setting wsrep_cluster_address to an empty string, but then the bootstrap command was implemented so that a user doesn't have to change configuration in my.cnf during this.

tl;dr: "bootstrap" is a different thing from "start" and running a bootstrap if start fails leads to confusion and data loss

Maybe it's a bit late to say, but, anyone checked databases/galera ?
Isn't it related to our work?

The WSREP patch enables pluggable replication engine replacements. Galera is one implementation of such an engine.
After this lands, the next step is to update databases/galera to the latest.

In D9427#195662, @lifanov wrote:

The WSREP patch enables pluggable replication engine replacements. Galera is one implementation of such an engine.
After this lands, the next step is to update databases/galera to the latest.

I didn't told my meaning quite good, Sorry about that.
I simply meant "maybe we can turn that port into slave of this one" :)

They don't really share code. They come from different tarballs, etc.
One is a shared library that gets loaded into the other but both have independent releases and updates.

In D9427#195667, @lifanov wrote:

They don't really share code. They come from different tarballs, etc.
One is a shared library that gets loaded into the other but both have independent releases and updates.

Aah! I see 🙂 .
Thanks for explanations 😉🙏 .

I'm adding swills to review. I would like to move this forward, but I don't have any feedback from portmgr folk :)

Unlike original MySQL 5.6 port, MY_DBDIR would be dereferenced exactly once.
I can add it back in if this is preferable.

I'll add it back for the sake of similarity with other MySQL ports.