From nobody Tue Oct 21 13:51:47 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 4crYch3YCxz6BYZG; Tue, 21 Oct 2025 13:51:48 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4crYch34RMz3DQ7; Tue, 21 Oct 2025 13:51:48 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1761054708; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WFeefxLm+6xbRDLtfxXL9nAJkbVzFSm6y8GZfTocfbE=; b=uUaY1bE3HUzCQnACgkzPIJbM2Au4B3kyL/2qBkIFd1+9lzmJHJN5l7kWOZfRWH+FZu6trm aDd2m6ZN/oNzmIJHKYHX/MEl2vV30EI4StXObo1Bo0RobbO48v1Su3eyzzEGKSpPcvv4PA 0YWLBy+pDAMCRriTo7VVwwzYH8I0Zwi/g+Y7bePBs+iCEp3y3hrgCyVIAIUm++a5/oxtyb ZxHgE/mmR1HvwbPqRTyWpMoTMjOpszTFB84dh2e5GOs05Oh07zoCzBELZ3U+pPN+6FnBP/ h+5bYr/mFVjeVkMhd038o9wF9Z6AJo6IUEBqxjdoyTtTMTrTBAu83vncwg+fdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1761054708; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WFeefxLm+6xbRDLtfxXL9nAJkbVzFSm6y8GZfTocfbE=; b=M1XRH7WdGmTDNhepEj8HxpG4X6Do5Lkdm0jaVqmQcrD6owIjBukI6YGzdErxkMgWQWLu+Y m7mZcUXN3XS1+UgyJQdln4yt/j9RkGiBZkUrcXCyyeDwe/XwKqIesB60wbnctbaZOREaul NNcXc5OGfo51E4vvfSecEvvCGmRxqtU4AoW4zpNKw24ae6DHEsE8SJuRitQjk5iitxqDsQ OFi3y0Mg+JjQQGZ9hQm78qK4ML6Z21sl2No0OecnY+NjaZUod1GGmRx3Gx1JiNmrIJuzbj dmJHK9ylV9J7A/pEEFlKir4IGDjhE/2xjDw+me9yncBjLXeVAOAQh2O/vKNZJw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1761054708; a=rsa-sha256; cv=none; b=VgOKZax7bXgjsF8CX+13kXnxQz20IWLNqPKpHItmxZ0smcM1ZIQWDwfBiEskmNdEQT4f4W DuJ43mUKrae3ZcBP9Rn4T/P2Tvs48EIiOUaZalWhhHIlhhTw7Isq+W54g27ElB/Ba8D4RX aPKoVG/kUJscvcUMDbFqvIt5zzgHptUVV/d5+t1radJgeuJczwU6n/XbHweKnjr4gReC4Y dygVTiil8lBsH0cSXDTb3LvvQzDVxp9wjykynwJxWAyJom+AVmlZ2JVu3VsPgn0b014ZpK cNQDcSlVQAJwEWZuwuj5bD5AKpkDfl4J1DuKY/6mBzyQnbfaQcrtKGxbUs0UMQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2601:5c0:4202:5670:20c2:9c23:87dd:26f7] (unknown [IPv6:2601:5c0:4202:5670:20c2:9c23:87dd:26f7]) (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 did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4crYch1PkFzNsk; Tue, 21 Oct 2025 13:51:47 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <1e0fa955-a6d9-4c21-9620-3eea6d7682be@FreeBSD.org> Date: Tue, 21 Oct 2025 09:51:47 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: git: 74a6bb524e5b - main - Makefile: Don't allow install{world,kernel} with pkgbase Content-Language: en-US To: Warner Losh Cc: src-committers , dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org References: <202510171914.59HJE0uo036247@gitrepo.freebsd.org> <228220a0-c819-4c51-92d3-5357e925c81d@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 10/21/25 00:20, Warner Losh wrote: > On Mon, Oct 20, 2025 at 1:44 PM John Baldwin 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= 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