Thank you for the input.
I will note that in the documentation patch for bsdinstall(8). This patch will be abandoned, the other two in the stack will remain, because they are essentially a cleanup with no functional changes.

Address suggestions:

Yes, I agree. My original plan was to only select the MANDATORY options by default.
But giving it a second thought, maybe I should change it to explicitly set default_lib32 to on (it is currently set to on because there is no default_lib32), and clearly state in the commit that this is to have 32-bit support for some popular ports by default (wine, steam, etc.)?

Hi @senguptaangshuman17_gmail.com, this revision is still missing a few tests. I plan to add them after this week's meeting.

Hi @0mp would you mind if I take a stab at extending this patch a bit further or maybe you would like to extend it?
For some context, I am currently working on adding a precompiled option to NanoBSD as part of a GSoC project. It requires using pkgbase, however I found it very useful to also add distribution sets for comparison. As such, we have decided to adopt bsdinstall's configuration options, that is, defining a NANO_DISTRIBUTIONS variable with the distributions you want in the final image. I'm pointing users to this manual page for more information about DISTRIBUTIONS.
My extension will consist of presenting more verbose distribution set information (obtained from the MANIFEST), which includes all the valid options the user can choose:

base-dbg.txz		"Base system debug info"			off
base.txz		"Base system"					on
kernel-dbg.txz		"Kernel debug info"				on
kernel.txz		"Kernel"					on
lib32-dbg.txz		"32-bit compatibility libraries (Debugging)"	off
lib32.txz		"32-bit compatibility libraries"		on
ports.txz		"Ports tree"					off
src.txz			"System source tree"				off
tests.txz		"Test suite"					off

The third column is what bsdinstall selects by default when running interactively (for reasons beyond my understanding, I would have selected base.txz kernel.txz by default as well).

Thank you for working on this!

Yes, this should be pretty straightforward.
I added the network project, just in case. Let's wait one more week, plus an MFC of one week after that.
If this is time-sensitive, let me know and I will commit sooner. Thank you!

OK, if this is indeed what you prefer, I would only ask that in the commit message at least some of the discussion in the PR is stated. Something along these lines:
The NETWORKING script was created to avoid conflicts between the NETWORK script and the network script (present on NetBSD) when the file system is case-insensitive. NETWORK was maintained as an alias for compatibility with old scripts... (please feel free to paraphrase).

Thank you!

Nice! I'm sorry, but I found one very minor thing. REPODIR is unset in bsd.pkg.mk, therefore creating the repo directory under /, I documented inline what I did in order to make it work.
Besides this minor issue and the missing machine-specific Makefiles you mentioned, everything else is superb!

Please see: D56118.

In D56117#1283524, @ivy wrote:

that sounds reasonable. note this blocks D56087, so i'm interested in the result.

Give me some time to test it, but I think it is better if we just update share/mk/src.opts.mk (and regenerate the manual page afterwards):

.if ${MK_BLOCKLIST} == "no"
MK_BLACKLIST:=	no
.endif

In D56070#1283471, @ivy wrote:

fwiw, i think this is fine to land before D56087 as long as you're only doing something like .export SOURCE_DATE_EPOCH in Makefile.inc1. that should be picked up automatically by the <bsd.pkg.mk> build.

edit: this is partly why i suggested using .export instead of editing the pkg commands.

Thank you! It works well now (overall). There are a couple of things that fail on aarch64 (described inline). Other than that, this is great. Thank you!

In D56087#1282872, @ivy wrote:

In D56087#1282809, @jlduran wrote:

I have briefly tested this patch, and I'm getting:

/usr/libexec/flua: /usr/src/release/packages/generate-ucl.lua:77: attempt to call a nil value (method 'match')

As if the previous clean step did something it should not do (it dirtied the repo). Please disregard if I'm doing something evidently wrong.

i will try to reproduce this here, but in the mean time, could you please share a full make buildworld / buildkernel / update-packages log?

In D56087#1282872, @ivy wrote:

In D56087#1282809, @jlduran wrote:

I have briefly tested this patch, and I'm getting:

/usr/libexec/flua: /usr/src/release/packages/generate-ucl.lua:77: attempt to call a nil value (method 'match')

As if the previous clean step did something it should not do (it dirtied the repo). Please disregard if I'm doing something evidently wrong.

i will try to reproduce this here, but in the mean time, could you please share a full make buildworld / buildkernel / update-packages log?

In D56087#1282790, @ivy wrote:

@jlduran, @imp: this may impact what you're working on for nanobsd.

In D56070#1282531, @ivy wrote:

i have a strong preference for using SOURCE_DATE_EPOCH here, if possible: it will avoid conflicting with some other pkgbase work i'm doing, and more generally seems like a cleaner solution as anything that needs that can easily consume it; this is information that should be generally available to the build system.

In D56070#1282516, @kevans wrote:

Specify the modification time (mtime) of the files to match SOURCE_DATE_EPOCH rather than the current time when creating packages.

Can you spell out a little more clearly in the commit message why pkg's automatic SOURCE_DATE_EPOCH usage isn't sufficient here, please? By all accounts it seems like this should be a nop, so I guess it's that SOURCE_DATE_EPOCH isn't exported into pkg's environment in these targets?

In D56013#1281115, @ivy wrote:

./boot type=dir uname=root gname=wheel mode=0755 tags=package=bootloader,utilities

i don't think this is right (and based on what i remember of mtree-to-plist, i'm not sure it'll even work). /boot should be owned by the bootloader package; if something is adding a package=utilities tag to it, whatever's doing that should be fixed.

• Previous revision stack was committed.
• All possible improvements that derive from this file, will be re-submitted.

In D55651#1274046, @ziaee wrote:

See ls for similar language.

Thank you! For taking the time to translate the handbook.
I just glanced over and found this minor nit.
I wonder why backup server is not translated as servidor de respaldo.
Servidor de reemplazo to me sounds like a replacement server.

• Add --libxo to usage message

Address suggestions:

• Do not manually reclaim memory

Refactor chunk of code:

• Prefer clear, separate if statements
• sizeof(char) is always 1

In D55610#1272421, @des wrote:

In D55610#1272406, @jlduran wrote:

Note that we want to keep the current behavior in makenetvfslist().

Why?

Note that we want to keep the current behavior in makenetvfslist().

Address suggestions.

Rebase

Address suggestions