Re: git: 74a6bb524e5b - main - Makefile: Don't allow install{world,kernel} with pkgbase

On 10/21/25 00:20, Warner Losh wrote:
> On Mon, Oct 20, 2025 at 1:44 PM John Baldwin <jhb@freebsd.org> wrote:
> 
>> On 10/20/25 10:59, Warner Losh wrote:
>>> Install* should eventually just do the right thing like ports: stage the
>>> packages, make the packages and the install from the packages.  16 time
>>> frame, though.
>>
>> Hmm, 'make installkernel' needs to still create kernel.old for those
>> of us doing development (or really, just running main.  The tb(4) driver
>> turned my laptop into a brick recently and I needed kernel.old so I could
>> recover).  AFAIK, pkgbase doesn't have any provision for doing that.  Also,
>> `make installkernel INSTKERNNAME=test; nextboot -k test` is a key part of
>> my workflow for testing kernels.  I'm fine with using packages to ship
>> updates to users running stock sources, but please do not make it harder
>> to do development.
>>
> 
> Yes. Though I'd hope we'd get slightly better BE integration. Then it
> doesn't matter... unless you're running UFS root... so something needs to
> happen. But it's not clear to me if the stagekernel stuff should do that,
> or if *ANY* update from pkg to /boot/kernel (or the booted kernel)
> shouldn't do the /boot/kernel -> /boot/kernel.old rename, sysctl tweaks so
> ps can still fine the kernel if it needs it.
> 
> 
>> When hacking on userspace components I often need to be able to do
>> just 'make install' of a single binary or library onto an installed
>> system knowing that a future installworld or `make install` will revert
>> to "stock" binaries later.  Please don't break that.  It's like when
>> I work on changes to GDB or LLVM, I use the native build system to build
>> the modified version, I don't try to hack up a port to build a package
>> with the extra changes I have either in a working tree or committed on a
>> feature branch.
>>
> 
> Oh yes. I was thinking that only install{world,kernel} would change to
> depend on the staging + packaging and then  accomplish this by doing a pkg
> update. The per-directory stuff I didn't think should change (though I
> honestly wish we'd have the 'stating' just be a metafile creation with a
> contents= tag in the METALOG instead of so much copying.

I think the only friction here is that 'make installkernel' is the 'make install'
analog for a kernel.  'make installworld' is more obviously a meta operation,
but `installkernel` is a bit different.  It's also important to not break
`make installworld TARGET_ARCH=<mumble> DESTDIR=/path/to/rootfs` which is another
use case I at least use quite frequently to build cross-arch disk images for use
in QEMU (or to cross-install onto the SD card I use in SBCs).

Also, I know that for cheribuild we certainly cross-build OS images (including
a cross-install kernel/world into a rootfs) on Linux and macOS, so switching to
packages adds another dependency (pkg) to that.  This is probably easier to
make work if pkg is in the base system and built as a cross-tool rather than an
external tool (though an external tool can work).

-- 
John Baldwin