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.

okay, that sounds reasonable.

also from the PR:

the problem reported in the PR is:

In D53051#1225647, @cperciva wrote:

This seems to have stalled; ok if I take it off the 15.0 issues list?

In D53491#1225645, @cperciva wrote:

This isn't intended to land in 15.0 any more, right?

In D53605#1223886, @jlduran wrote:

Perhaps the discussion can be if we want to make WITHOUT_BLOCKLIST the default? That would be understandable, since it has a low usage rate, I would approve that.

also update mtree

In D53605#1223871, @jlduran wrote:

Just to make sure I'm on the same page, because to me having FreeBSD-blocklist-lib and FreeBSD-blocklist would be like having FreeBSD-ssh and FreeBSD-ssh-lib.

fix the UPDATING text to match the use of LIB_PACKAGE

In D53484#1223366, @glebius wrote:

Note that there are tests that use routed :(

In D53576#1223087, @emaste wrote:

Will runtime need a dependency on libcasper now?