From nobody Tue Oct 21 04:20:19 2025 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4crJxd3LY5z6DmPG for ; Tue, 21 Oct 2025 04:20:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4crJxd0cQkz3Qfm for ; Tue, 21 Oct 2025 04:20:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-33ba5d8f3bfso4458481a91.3 for ; Mon, 20 Oct 2025 21:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1761020430; x=1761625230; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xBqpHbGLK+cwVpL/17YSug7JJJDysBFnlQTXKHN0gQo=; b=tpRo9Br2HpV7iDxzfCPytZAUpLH+J1135DC0ToeTvXsq8hnC5ATRlYrhZQZdQSClUu IUMRRnzq3tV/JHiuH9sDiwU8xUmxUPh85H6llBA9P93FDMErNAk9EXiW1F354UlSlORp eoKTCHwOQvanytvjDyY4cV/uMwpoa9lrU6DVrb2ZMw9EyZanMLkRV4ljKu5Ez//9cL5Z hOLLM7h5TGpaa7Y6/hIUd8igEMAU7k+67V2d4Ap1iijMzrinX99L07k5VOnhq2KTc7oa qzgtBBhAzvDAq99GvYgiMhCGobVpMkrY4kC8Brjq7M5TGz0G/3zlAzpaZqPLAh/RgV/q CT8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761020430; x=1761625230; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xBqpHbGLK+cwVpL/17YSug7JJJDysBFnlQTXKHN0gQo=; b=icXZsVN3l3LzBMZzBhY4nqkLau9WGl5ORpHsgs+ahUgMIRddCFzl+nvZixNwovz5wp rbpA+xE4RLUjYU97wU67dJdYbMbCWBa3L5WQ15RxMBDonEgGJQ5ze5yMfQ06a5sI3cKs BCbN7uzPSdgrouThQKdG2/z5R8q6oqqcWeEGJyPPTkynDnwnfetujoTiJhM1q5KAAye7 RyeSvCyiA5WdbS+Nw9n+ALsbFSmPBVKSuLhs+anWhGhV6edXdlCSy1cAo1Dn9oxjTlEz KVuOtIgkFVyEBV07ThUJZ/zhzMeYNdRchMeby0n2dG9fW8pPvApHddlMT/A+WGdONtiX suqQ== X-Forwarded-Encrypted: i=1; AJvYcCXVwnm4g57zCds55fg1Wr2tgo4ZC974sz8W/5rjmyXg8qA4Ymc4uPJNRVSBEErbZ2rmF0y2dZ1TCbV1gthuB9CMgctkfA==@freebsd.org X-Gm-Message-State: AOJu0YyxMdWqvxW415R7SqhCD6yYca3l72Y4WNbvujMKwj+SoBiydbt6 wUqh68USZdpW48e2nfHoVFlC+KWe7JWI1hf5JbUOurlElp+SnjfVl53566/DQr1v30q9V5MkTLR SVZNkqWtARXnI2Hd9mk9rgAUB65yDU/ogfhG+9VpxZw== X-Gm-Gg: ASbGncsEXSIg0TmAiecOH73e+G/b38FtqRj0eZ5maO0H2ZAdzMPOywYJbDakAtnRPRq 7h2/ExCQ7PZ26mACJOSVOrAQiZF5Cls1yz/DhyYk36mQvS5UFaSflOOdz7nVDgZXrhcx1DGL+Yp KXdVtlVdwesoquy7E5Kjb8mjnFRKS/CGRde7HBIF9qSzcb36rWeJTRUZrkfiduoRNRNISKJh02u 9qA73pAF6ETu7fo+KQqltW+XD4Q8EqowyFwQrF66XMK2loGQMb4JSJTdWOAAljyyHl7JmtXe2s6 mnN4VFc= X-Google-Smtp-Source: AGHT+IGH1+5PA9vxf2AXU0/4+gOqTgE3Df5FkEs/BS40E8e5mfwQHPJ7GKkk3HLhBd/gedG5mN34zJLglBzOqWcGAvQ= X-Received: by 2002:a17:90a:d60f:b0:32b:dfdb:b27f with SMTP id 98e67ed59e1d1-33bcf8e4539mr21012779a91.17.1761020430341; Mon, 20 Oct 2025 21:20:30 -0700 (PDT) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 References: <202510171914.59HJE0uo036247@gitrepo.freebsd.org> <228220a0-c819-4c51-92d3-5357e925c81d@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Tue, 21 Oct 2025 00:20:19 -0400 X-Gm-Features: AS18NWCt3kPyOh3NFMy3RNzlGyHOAGfZd__KpX45HK-vdhCHzM-DuniPy7RLx7o Message-ID: Subject: Re: git: 74a6bb524e5b - main - Makefile: Don't allow install{world,kernel} with pkgbase To: John Baldwin Cc: src-committers , dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="0000000000003168f90641a38512" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4crJxd0cQkz3Qfm --0000000000003168f90641a38512 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 20, 2025 at 1:44=E2=80=AFPM John Baldwin wrot= e: > On 10/20/25 10:59, Warner Losh wrote: > > On Mon, Oct 20, 2025, 8:42=E2=80=AFAM Lexi Winter wro= te: > > > >> John Baldwin wrote in <228220a0-c819-4c51-92d3-5357e925c81d@FreeBSD.or= g > >: > >>> 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 fro= m > 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 > >>> - (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 th= e > > 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. Als= o, > `make installkernel INSTKERNNAME=3Dtest; 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=3D tag in the METALOG instead of so much copying. Warner --0000000000003168f90641a38512 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 20,= 2025 at 1:44=E2=80=AFPM John Baldwin <jhb@freebsd.org> wrote:
On 10/20/25 10:59, Warner Losh wrote:
> On Mon, Oct 20, 2025, 8:42=E2=80=AFAM Lexi Winter <ivy@freebsd.org> wrote:
>
>> John Baldwin wrote in <228220a0-c819-4c51-92d3-5357e925c81d@Fre= eBSD.org>:
>>> On 10/17/25 15:14, Lexi Winter wrote:
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Makefile: Don't allow instal= l{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?=C2=A0 I guess it is something like:
>>>
>>> - pkg install sources if not already (or git clone the right b= ranch/tag)
>>> - etcupdate bootstrap
>>> - <destroy the pkgbase repo> (clearly can't just use= pkg delete with a
>> glob, so need
>>>=C2=A0 =C2=A0 something else)
>>
>> this should eventually be in the Handbook.
>
>
> Install* should eventually just do the right thing like ports: stage t= he
> packages, make the packages and the install from the packages.=C2=A0 1= 6 time
> frame, though.

Hmm, 'make installkernel' needs to still create kernel.old for thos= e
of us doing development (or really, just running main.=C2=A0 The tb(4) driv= er
turned my laptop into a brick recently and I needed kernel.old so I could recover).=C2=A0 AFAIK, pkgbase doesn't have any provision for doing tha= t.=C2=A0 Also,
`make installkernel INSTKERNNAME=3Dtest; nextboot -k test` is a key part of=
my workflow for testing kernels.=C2=A0 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 matte= r... unless you're running UFS root... so something needs to happen. Bu= t it's not clear to me if the stagekernel=C2=A0stuff should do that, or= if *ANY* update from pkg to /boot/kernel (or the booted kernel) shouldn= 9;t do the /boot/kernel -> /boot/kernel.old rename, sysctl tweaks so ps = can still fine the kernel if it needs it.
=C2=A0
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.=C2=A0 Please don't break that.=C2= =A0 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<= br> 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 + pac= kaging and then=C2=A0 accomplish this by doing a pkg update. The per-direct= ory stuff I didn't think should change (though I honestly wish we'd= have the 'stating' just be a metafile creation with a contents=3D = tag in the METALOG instead of so much copying.

War= ner
--0000000000003168f90641a38512--