I'm missing something. Are there multiple ports that provide doxygen binaries?

Ah sorry, forgot to reply here. Someone reported an error that seemed like it was caused by this, so I pushed the fix. Turns out he had some sort of environment contamination (building from ports), so it was a bad assumption on my part.

What is the status of this patch? What help can I be of here? I'll hold off on updating to 2.2.18 (just released) so as not to interfere here.

Sorry Alan, this was breaking the build on 11 so I committed it.

Normally I push hard against avoidable dependencies, but I think the right thing to do here is to make makeinfo non-optional. Major gnupg dependencies (like gnutls, libgcrypt, m4, nettle, and autoconf) depend on texinfo, so there's really nothing to gain from hiding it behind a MANPAGES option (which is normally used when dependencies are ludicrous, like pandoc or whatever nonsense python thing cmake uses).

This isn't the right approach. Manpages aren't docs like FAQ and HACKING and DETAILS; they're manpages and their existence shouldn't be controlled by the DOCS option.

I guess I should add to please make sure that make -C ${WRKSRC} check completes successfully.

I haven't tested this (I have no way of actually testing it), so I'm relying on you there. You definitely have my approval to commit this whenever you're ready.

After updating the DOCS_BUILD_DEPENDS (and also bumping PORTREVISION please), feel free to commit this anytime.

I'm fine with a date change in that context.

This seems tremendously fragile. Unless I'm misunderstanding, these massive patches would have to be regenerated for every update (assuming changes), which---while I appreciate the patch coming down the pipeline---I don't relish the thought of being responsible for.

In D22450#491430, @jhb wrote:

I think this probably warrants an exp-run before committing?

I applaud this move. It sets a great example of where individual maintainership should head: shared responsibility across the consumers who need to leverage it.

The committed version is a little weird. Sometimes the minimal dependency set is the ideal set, so saying it should never be it is misleading. Also, the last sentence isn't a sentence.

> Thanks. Some time ago @tobik wrote 6.5.8. Building Go Applications section that covers this process in details. It is tailored for Go modules, but I doubt that there will be much new Go software written that don't use them.

I'll approve it.

bsd.default-versions.mk is maintained by ports@. There’s no approval needed from our end on it.

Ah okay. I thought this was separate from OPTIONS.Then maybe:

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...