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

On Mon, Oct 20, 2025 at 1:44 PM John Baldwin <jhb@freebsd.org> wrote:

> 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.
>

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.

Warner