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

rebase on D54291

suggest using INSTKERNNAME for installkernel

In D54164#1239215, @christos wrote:

I actually think the latter is a good idea, and probably more robust.

i've tested D54282 rebased on this diff and it seems to work fine.

after my last comment, i ran into an unexpected make(1) crash while running this patch. i need to do some more testing to see if this is actually the cause, but i suggest holding off on landing it for now.

In D54282#1240666, @jrtc27 wrote:

I can make NO_INSTALLKERNEL less gross if that would help?

In D54282#1240471, @jrtc27 wrote:

To avoid breaking existing users of distributekernel (which is what we
currently use to stage the kernel), reimplement stage-packages-kernel
to run make install itself rather than changing the existing behaviour
of distributekernel; this means release builds and other downstream
users are not affected by this change.

Does the confusingly-named NO_INSTALLKERNEL not do what you want?

add UPDATING

this is basically ready, but there are some unresolved issues:

i wonder if it's worth adding a note about reinstalling ports/packages after upgrading. a lot of people don't seem to understand this and break their system, because they don't know how to become root when sudo isn't working, and the message from freebsd-update is still quite weak even after it was changed recently.

In D54257#1239773, @jhibbits wrote:

Isn't make.conf also read for userspace builds and ports? I think we still support 32-bit userland. Would there be a corresponding change to remove the i386 bits as well?

i've added this patch to my local ppc64le build and haven't noticed any problems so far, but i'm not really qualified to say if it's actually correct or not. (that said, i tend to agree that if we actually need to cache flush here, this seems like an ABI issue that needs to be fixed elsewhere.)

but this suggests it's safe to use make installkernel if you're using INSTKERNNAME, which isn't true. it may be true, but it also may be safe to use it without INSTKERNNAME set at all - it depends on what you set it to and what pkgbase kernels you have installed.

In D54235#1239096, @jlduran wrote:

I wonder if changing it to: tags=package=bsnmp,dev solves the issue?

please include

Specifying a non-default kernel name with INSTKERNNAME means that the
user will not conflict with a pkgbase kernel, so skip the check.

i'm not familiar enough with the OCI build to review this, but the change looks right: we shouldn't be duplicating information that's already in /etc/pkg/FreeBSD.conf. this would also fix downstream users (like me) who ship a modified FreeBSD.conf.