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

On 10/20/25 10:59, Warner Losh wrote:
> On Mon, Oct 20, 2025, 8:42 AM Lexi Winter <ivy@freebsd.org> wrote:
> 
>> John Baldwin wrote in <228220a0-c819-4c51-92d3-5357e925c81d@FreeBSD.org>:
>>> On 10/17/25 15:14, Lexi Winter wrote:
>>>>       Makefile: Don't allow install{world,kernel} with pkgbase
>>>
>>> Can we document how users who want to build from source can do so from a
>> new installation
>>> that uses pkgbase?  I guess it is something like:
>>>
>>> - pkg install sources if not already (or git clone the right branch/tag)
>>> - etcupdate bootstrap
>>> - <destroy the pkgbase repo> (clearly can't just use pkg delete with a
>> glob, so need
>>>    something else)
>>
>> this should eventually be in the Handbook.
> 
> 
> 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.

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.

-- 
John Baldwin