i put a fair amount of effort into not making bsdconfig a required part of the system and don't really want to see it come back. sysrc can't really be decoupled from bsdconfig, at least in the current implementation, because it's just a thin wrapper around what bsdconfig does.

this might be a better question for arch@, but at least to me, it doesn't make sense to keep code for removed architectures in the tree: either it will bitrot and stop working (in which case there's no point having it) or it will create effort to maintain it even though we don't support it.

In D54542#1250509, @cperciva wrote:

Please check with the CHERI people in case this will cause problems for them though -- I think they were holding off on pkgbase for a bit, and they're an important downstream for the project.

In D54542#1250509, @cperciva wrote:

Not sure if you were planning on MFCing this, but if you are we should discuss further before that happens. There has been some release build breakage in HEAD lately so I want to make sure all the issues are fixed there before anything gets MFCed.

okay, i don't object to this but i feel like (at some point in the future) we could have a better solution somehow.

the only purpose that RFC8781 mentions for having multiple PREF64s advertised is renumbering, in which case the lifetime of the deprecated prefixes should be set to zero. iiuc, this diff allows that by setting pref64lifetime0, pref64lifetime1, etc. - can i check i have that right?

are there any objections to landing this? i'd like to get started on multiple kernel support for bsdinstall, and it would be easier to get the other release changes in first.

ideally these should have a package= tag, but i'm leery about adding those without more testing, so that can wait until someone (me) comes along and adds package tags for everything in this file.

In D54702#1249777, @christos wrote:

@ivy Makefile.inc defines:

PACKAGE?=	sound

Is it a problem if the inclusion is removed from here?

i'd suggest adding a Fixes: trailer to the commit message, these are useful for people who maintain their own branches/forks.

i think you also want to add /usr/share/pkg/triggers. currently only usr.bin/mandoc installs a file here, but more things will in the future.

okay, but even if you know what you're doing, you still aren't going to get security updates :-)

this means people won't get security updates for up to a week. is that acceptable?

add releng since this touches release/ now.

• rebase after D54291
• fix the symlink sometimes having the wrong path
• make the symlink relative instead of absolute
• fix a wrong dependency for the kernel-dbg package
• since the install media uses kernels_autodetect=NO, explicitly set the kernel to GENERIC. the user can override this if they want the media to use a different kernel.

use a "." form for the release sets, so RELEASE_MEDIA_SETS_BOOTONLY
becomes RELEASE_MEDIA_SETS.bootonly. this makes it more clear that
it can be set for any media type.

use minimal for bootonly by default

fix the metalog mode for /var/db/services.db

In D54539#1246074, @jrtc27 wrote:

Seems like this is a confusing result of "If start is greater than end, the words are output in reverse order"

use .elif to make this a bit neater