From nobody Tue Oct 21 04:20:19 2025 X-Original-To: dev-commits-src-all@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 4crJxf3Mxnz6DmBT for ; Tue, 21 Oct 2025 04:20:38 +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 4crJxd1YCRz3Qsm 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-33226dc4fc9so4708376a91.1 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=ntn/2rx6AieKRvbpXanR8PywWS0swXWHHbt6N+TcS3KXrB83ur2hueZiZ19BjwSIBq ggHrfh+5qJE1pJHKg1MokFHMhT90GCR1XcPvlwtGo1an4nGXOnEgXXxWlBSkkateCu2t RtaPBI1vM2sxUL01eYafIuRDB1exnlMA4CyHsp5MGt/+pd37aqoh+4pK7mzPAPsbgJYo PV+iuOXgG1eCJWxuQ9eFyBJyOyWju2HkSEBHts9B9JDuFLY/C6ue6rr93Nd++dlNIO0W lJL2dHIDaue73sHq1o3SR2eztAMgCcjP0DAaqkXh1D8aZq3HXUE8r3xZRLKoKjhNIvLe 8mYA== X-Forwarded-Encrypted: i=1; AJvYcCXP3VJSUQFRPKdtEsszrmdGHYPiioediUsLoAGC88NB+EAW7+QN9x7X0bbsn6tb5mRQz621bN67b1Q7N17CjN+nfpdd@freebsd.org X-Gm-Message-State: AOJu0YwBDL6N5YXBnChxucbhQH7vqxRVbBbJovbKDB7blQqi1ZqXFGmD cbwoQAcqR8j5XcotNQHqRhYo4+tvok1r/48NmZsB+JjILLlJ8aPqg0hKlZg7uNOMZjQ8y3FhlVf 1DkhEhSHYG1wtvzj6s0feXKhWHgl0HbTKSFojcFbRFg== X-Gm-Gg: ASbGnctnNDuL2DclASOFYAaQhwKaBPpl266K9MMbTyF3Gb3fEzSc059jc93OTpsDCJ6 zGQYU21OZeTlq9nzDwICZIo7w8k3SUawTNWAYmOFepLzBUP/ayqAsTuNnIKNe+x3PSgdK3lHCJl ISx+xr0j2Izv/v9PM3EPXRkPtohHtebgMHDuUKeTftfthTZbFtKNnQyVYlb5BF9dsCop1/sVRIW 7k9exDAv4EggB0lzEW5oW9t1vgqW59/FT8BLnqwLVpirDwB/nZO3FM28l8/BEuO6AuVNxrxKUMY JgiPoD0= 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 all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@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: 4crJxd1YCRz3Qsm --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--