packages: Always install kernel as /boot/kernel.NAME

[ivy]

Summary

Currently, when multiple kernels are specified in $KERNCONF when
building base packages, the first kernel would be installed in
/boot/kernel, and the remaining kernels would be installed in
/boot/kernel.NAME.

For example, if KERNCONF='FOO BAR BAZ', three packages would be
created:

• FreeBSD-kernel-foo, installing in /boot/kernel
• FreeBSD-kernel-bar, installing in /boot/kernel.BAR
• FreeBSD-kernel-baz, installing in /boot/kernel.BAZ

This behaviour is not desirable, because it leads to unpredictable
results when building individual kernels; the "default" kernel always
needs to be built as well to ensure the other kernel(s) end up in the
correct place. Aside from that, it's also confusing to have the same
package install files in a different place depending on how it was
built.

Fix this by having the packaged kernels always install in kernel.NAME.

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.

For the FreeBSD-dtb package, which uses files installed by the kernel
build, take the DTBs from the first kernel listed in KERNCONF. This
preserves the previous behaviour, and since DTBs are always installed
in /boot/dtb, the kernel name issue doesn't affect them.

Remove the "flavor" bits that were previously used to build the -dbg
package containing the debugging symbols. This was confusingly named
because the kernel and its debug symbols aren't flavours of the same
thing, they're different things. This also means we can provide a
separate kernel-dbg-all.ucl template for the debug packages, making
the comment and description more clear.

Remove the _kernconf option from mtree-to-plist.awk, since it's no
longer used.

To prevent breaking upgrades when the kernel moves from /boot/kernel
to /boot/kernel.GENERIC, add a new kernel-support package containing
a trigger that manages a symlink at /boot/kernel. If /boot/kernel
doesn't exist, or is an empty directory, or is a symlink to an empty
directory, remove it and create it as a symlink to an installed
kernel. Try to prefer a GENERIC kernel for this, otherwise pick
any installed kernel. If the user modifies the symlink to point to
a different kernel, the trigger will leave it unmodified.

Usually this will be done by bsdinstall and the symlink won't be
changed after that (unless the user removes the GENERIC kernel),
so this is mainly to handle upgrades.

Update freebsd-base.7 to document the new behaviour.

Suggested relnotes text:

Kernels installed from packages will now always install in
/boot/kernel.NAME, rather than the first built kernel (usually
GENERIC) being installed as /boot/kernel.  The kernel package
will maintain a symlink to an installed kernel at /boot/kernel.
For more details, refer to freebsd-base(7).

MFC after: never
Relnotes: yes

[ivy]

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

• pkg seems to have issues running the trigger when using pkg -r, i'll follow up on this separately.
• the trigger doesn't work on ppc64le because /boot is a FAT filesystem. this just means the user needs to edit /boot/kboot/kboot.conf by hand.
• do we want bsdinstall to add kernel="kernel.GENERIC" to /boot/loader.conf, or should we teach the loader to resolve the symlink (to set kern.bootfile correctly), or something else?

[ivy]

add UPDATING

[jrtc27]

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?

[ivy]

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?

possibly, but this is an awful hack that works by adding incorrect entries to ${BUILDKERNELS}, which means the logic for create-dtb-package would probably need to be updated to work around that... the amount of new code for this specific change is very small, so i think i prefer doing it this way.

[jrtc27]

In D54282#1240665, @ivy wrote:

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?

possibly, but this is an awful hack that works by adding incorrect entries to ${BUILDKERNELS}, which means the logic for create-dtb-package would probably need to be updated to work around that... the amount of new code for this specific change is very small, so i think i prefer doing it this way.

I can make NO_INSTALLKERNEL less gross if that would help?

[ivy]

In D54282#1240666, @jrtc27 wrote:

I can make NO_INSTALLKERNEL less gross if that would help?

if you felt like doing that i'd be happy to remove the custom make install bits from this change. i think my only concerns are that 1) it doesn't lie about BUILDKERNELS, and 2) the first kernel is not treated any differently than the others (which might already be the case, i haven't checked).

[jrtc27]

D54291