Portmgr note: I wonder if we should standardize "normal" here.

Portmgr note: I think we need to slow down and not add FLAVORS -- and only convert existing slave ports. We have technical challenges to adding more packages right now, namely that the build times are exceeding the scheduled time for them and hitting some various filesystem limits (like 32k packages)

Portmgr note: This should really be handled by the framework (conflicts of flavors)

Right now, there are 3 ports that have flavors:

devel/kore/Makefile:FLAVORS=    default notls
finance/gnucash/Makefile:FLAVORS=               guile2 guile1
net/bird/Makefile:FLAVORS=      ipv4 ipv6

I'm not sure there can really be a "default", or "normal" standard for the first flavor, it really depends on what the port is doing with it. I'm sure there will be many with "x11 nox11" (or the other way around).

Well, CONFLICTS are only of any interest if you are building stuff manually, it tells you early that what you build will not be buildable or installable.

I do not think it would be easy, and fast to have helpers like:

lite_CONFLICT_INSTALL_WITH= normal
normal_CONFLICT_INSTALL_WITH= lite

Because they would need to get the other package name, which means a sub-make.

I recommend "default". The opposite of default is non-default, but the opposite of "normal" is "abnormal. Those poor packages are going to develop self-esteem issues.

Here's some verbiage:

When FLAVORS are based on a specific characteristic (such as with and without x11 support), name the flavors based on that characteristic:

FLAVORS=   x11 nox11

When FLAVORS are based on standard vs. nonstandard configurations, name the main flavor default:

FLAVORS=   default lite

The first listed flavor is the default, so make sure that it's the configuration that most users will want.

default in my opinion would be better. I chose normal because this is the docs example. Wasn't sure if it was a standard default/first flavor name.

[1] https://www.freebsd.org/doc/en/books/porters-handbook/flavors-using.html

Don't know very much about the technical challenges you're talking about, but this commit isn't super important for the time being. It is more of a nice to have optional flavor.

I changed the doc to use default.

Maybe it could be kept on the back burner for later when the infrastructure problems are fixed.