Date: Tue, 21 Oct 2025 09:51:47 -0400
From: John Baldwin <jhb@FreeBSD.org>
To: Warner Losh <imp@bsdimp.com>
Cc: src-committers <src-committers@freebsd.org>, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org
Subject: Re: git: 74a6bb524e5b - main - Makefile: Don't allow install{world,kernel} with pkgbase
Message-ID: <1e0fa955-a6d9-4c21-9620-3eea6d7682be@FreeBSD.org>
In-Reply-To: <CANCZdfph4nAaan2Y1gXsWnWkgitD3FHR_6%2B2KHUTQhbHNtOytg@mail.gmail.com>
References: <202510171914.59HJE0uo036247@gitrepo.freebsd.org> <228220a0-c819-4c51-92d3-5357e925c81d@FreeBSD.org> <aPZKLa0kTvovlqMP@amaryllis.le-fay.org> <CANCZdfoJSHrOWX%2BuZeFT6_UwfFi4yv8h%2BeKY9nUfB0oeHYQNPg@mail.gmail.com> <a1f77f46-a6cf-46b8-9fc3-c9a1cf485e0a@FreeBSD.org> <CANCZdfph4nAaan2Y1gXsWnWkgitD3FHR_6%2B2KHUTQhbHNtOytg@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1e0fa955-a6d9-4c21-9620-3eea6d7682be>