On 10/21/25 00:20, Warner Losh wrote:
On Mon, Oct 20, 2025 at 1:44 PM John Baldwin <[email protected]> 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
