Ok. So, my concern here is that (a) I don't know what an "extra dependency" looks like, and (b) sometimes the configuration that would benefit the most people is the minimal or maximal set.

This automatically flagged @portmgr because of go.mk. It's a formality, but you certainly have our approval for it.

It would be nice to put a note in CHANGES about this with a quick blurb on how to use it.

This is a good idea. The ability to continually improve FreeBSD shouldn't be blocked by the possibility of fixing a few small merge conflicts. We want people working together and helping each other out, not treating team ports as siloed and immutable.

Perhaps these could say Git repository support or, even better, Git code repository support.

I suspect that it's not been listed mainly because we haven't had a userbase segment express interest in widespread testing of it.

In D20394#451999, @swills wrote:

By the way, SUBDIR in ports/Makefile and VALID_CATEGORIES in Mk/bsd.port.mk are both defined with += from the start, so you can define additions in /etc/make.conf and they won't be overridden.

In D20394#451916, @kmoore wrote:

I'll be happy to back out that bit if its a huge concern, but let me first lay out the scenario we're trying to solve, and I'm curious to know if there's some better way to solve this that we've been unaware of for years.

I appreciate the work there, Kris, but a ports tree package is simply counterproductive. I am 100% opposed to a ports tree being in the release images in the first place; giving users another way to install a stale version of the tree is setting users up for failure. We do not support stale ports trees in any way; we shouldn't make it possible for users to get them in the first place.

I should add here:

Thanks, those new categories make more sense to me.

In D20394#449271, @imp wrote:

The usual worry here is overwhelming the user with options because we have so many...

So, I'm just going to throw this out here. This is just a neat feature of the ports tree that the src framework might choose to leverage.

I see what you mean. Here it takes anything between parentheses as a sign to exit.

In D20698#447300, @mat wrote:

Then if the MFH line contains anything else than a branch name, say:

MFH: 2019Q2 (security update blanket approval)

There is no need to send an email because it will already have gotten committed.

I'm having trouble understanding how this is materially different than all the kmod ports relying on /usr/src for their builds, and that's not verified at all either. Also, in the future, we may have a src git repo, and we're looking at having signed commits so we'll know that a tree has integrity.

Oops, there was a typo there.

+1

In D20394#444436, @mat wrote:

In D20394#441905, @kmoore wrote:

Anyway, open to suggestions on where to next take this conversation to reach some consensus around these topics.

The consensus is that this does not belong in the ports tree.

In D20394#441438, @seanc wrote:

Integrity of the base distfiles is left to the administrator. [...] Said differently, if a release engineer can't ensure integrity of the source used to build a jail, the release engineer has bigger problems.

No, please don't do this. Those lines were put there for a reason and removal is supposed to be opt-in, not opt-out. I am opposed to this on principle.