Seems fine conceptually, a couple comments.

fix typo pointed out by @emaste

• s/answers answers/values/ as pointed out by @jbo

I've put the script in the rc package rather then adding a new utilities section for now.

Be a little more friendly to installations without mail bits. It's
unclear that this really matters, but it does appear to be at least
minimally possible to install a system without email support.

Move script into the default package (rc).

• fix BASIC-CI images (missing files)
• add some more abstraction to reduce the overall diff

• Add a comment about the etcupdate metalog bits
• Require that both or neither of WITHOUT_QEMU and NO_ROOT be set

Implement suggetions from @jrtc27

• Use shell variable substitutions instead of temporaries
• Use DESTDIR-relative paths in makefs calls

Restore to previous version

In D49310#1124766, @brooks wrote:

Implement suggetions from @jrtc27

• Use shell variable substitutions instead of temporaries
• Use DESTDIR-relative paths in makefs calls

Implement suggetions from @jrtc27

• Use shell variable substitutions instead of temporaries
• Use DESTDIR-relative paths in makefs calls

• Don't require WITHOUT_QEMU to have a value
• Rebase

This would be nice to do, but I've been unable to resolve the copyright issue and I managed to work around it.

FWIW, I looked into what it would take to retire this hunk of code the do the include to bsd.port.mk and it's a bit annoying due to a lack of guards on bsd.cpu.mk. I think it might work to have it included twice anyway, but it would probably be best to add some include guards, MFC them and wait for branches without them to drop out of support.

In D49134#1121137, @emaste wrote:

I took a look at making the output reproducible, and we can address this issue with that change as well -- D49141.

Brooks does raise a good point. I think I'd like to:

1. Move forward with D49141
2. Abandon this change
3. (Later) move D49141's source->target inode mapping into core makefs and use (fs, inode) as the key

Seems reasonable.

Seems plausible. I do wonder what happens if your input spans filesystems and there are collisions, but that would be a large, existing problem.

Seems reasonable.

Seems fine overall.

In D49048#1118546, @kib wrote:

"The to another bug" in the summary is either a too advanced english (for me) or a typo.