The "Any of:" part doesn't feel right to me, because it's restrictive. Can you maybe flip it around? "Applications, utilities, or games primarily[...] or study in general, such as: course-writing or course-delivery applications[...]". Something like that gives context and hints as to what belongs without restricting its ability to grow over time.

Generally, Uses/* macros provide logic beyond a straight dependency. When they do contain only depends, it’s typically for things where the actual dependency may change. For example, Uses/jpeg.mk only adds dependencies, but it’s because the JPEG library we utilize changed (and may well change again).

In D26667#601994, @0mp wrote:

It's probably better to keep those binaries not stripped for debugging. Instead, it might be better to document that they are not stripped on purpose.

Ah, that’s a good point about the distinction!

I know it’s late now because it’s already been committed, but I think this should be renamed to @empty. @rmdir was renamed to @dir because plists most logically express the contents, not what to do when they’re deleted.

Much as I’d enjoy it, pkg is the main but not the only installation mechanism. Preventing those users from shooting themselves in the foot is important—and the users who use ports/portmaster are often those who find anything else “too difficult.” Is there perhaps a way to simplify the maintenance burden? Alex makes a good-sounding argument about separating ZTS builds, but do debug builds really need a separate destination too?

Makes sense. Note that this will necessarily break on ports that rely on no backup files being created. There are a number that patch files that get installed with ${COPYTREE_*}.

Does -i... need to be stripped from REINPLACE_ARGS? Like ${REINPLACE_ARGS:N-i*} or something?