From nobody Thu Jul 31 01:24:50 2025 X-Original-To: freebsd-pkgbase@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 4bsrwq0zlYz63GdR; Thu, 31 Jul 2025 01:24:59 +0000 (UTC) (envelope-from marquis@roble.com) Received: from mx5.roble.com (mx5.roble.com [209.237.23.5]) (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 (2048 bits) client-digest SHA256) (Client CN "mx5.roble.com", Issuer "mx5.roble.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4bsrwp0dPYz40pR; Thu, 31 Jul 2025 01:24:58 +0000 (UTC) (envelope-from marquis@roble.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=roble.com header.s=rs060402 header.b=BrOxR3uY; spf=pass (mx1.freebsd.org: domain of marquis@roble.com designates 209.237.23.5 as permitted sender) smtp.mailfrom=marquis@roble.com; dmarc=pass (policy=none) header.from=roble.com Received: from roble.com (roble.com [209.237.23.50]) by mx5.roble.com (Postfix) with ESMTP id EE4A54B389; Wed, 30 Jul 2025 18:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=roble.com; s=rs060402; t=1753925091; bh=t7JxjJzqMtJDxzJv7dUaJtw3yTMxsFgpIOPLKht9G6o=; h=Date:From:To:Subject:In-Reply-To:References; b=BrOxR3uYqa6l8y0Wa+mkbGyjQiJa2Jhq7Ki2x98IXp1Xky6ckhKfqAgZ/ZRU5CIkX nca4rUPgvXSGXYosy7UoXMcb01hVi3TbWmKfXKxQ25UWlhP9BsbIjod0l7Yu0qe8FG u2a3leutk9XagL8TV4biof0AxkuVclnGctRTU67M= Date: Wed, 30 Jul 2025 18:24:50 -0700 (PDT) From: Roger Marquis To: freebsd-pkgbase@freebsd.org, freebsd-stable@freebsd.org, freebsd-pkg@freebsd.org, freebsd-current@freebsd.org Subject: Re: PKGBASE Removes FreeBSD Base System Feature In-Reply-To: Message-ID: References: List-Id: Packaging the FreeBSD base system List-Archive: https://lists.freebsd.org/archives/freebsd-pkgbase List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pkgbase@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Spamd-Result: default: False [-3.71 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.914]; DMARC_POLICY_ALLOW(-0.50)[roble.com,none]; R_DKIM_ALLOW(-0.20)[roble.com:s=rs060402]; R_SPF_ALLOW(-0.20)[+ip4:209.237.23.0/24]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:17403, ipnet:209.237.0.0/18, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-pkg@freebsd.org,freebsd-pkgbase@freebsd.org,freebsd-stable@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[roble.com:+] X-Rspamd-Queue-Id: 4bsrwp0dPYz40pR X-Spamd-Bar: --- On Thu, 31 Jul 2025, vimanuelt wrote: > ... the current architectural assumptions underpinning FreeBSD?s package > management model. The practice of overloading a single tool, namely pkg, to > manage both the base system and third-party software introduces semantic > ambiguity, violates long-standing UNIX separation-of-concerns principles, A single pkg command for both base and third-party packages would not be a problem so much as a feature for 3 reasons: 1) it has a long track record of working in Linux, 2) it facilitates 'distroless' and 'minimal' base and jails which, like Linux containers, are much desired as they reduce the attack surface and minimize pkg update overhead, and 3) yet another package command would be confusing and create unnecessary maintenance overhead. For those worried about recursive deletes, removing essential base packages with a '-F' flag (force base too) and/or '-RR' (recurse base too) could potentially limit unintentional dangerous actions. Either way it would IMO be simpler and more intuitive if all pkg flags were base-aware rather than requiring a different command with a slightly different set of flags. Bottom line: FreeBSD's current inability to create a minimal base, much less minimal jails, is a HUGE USABILITY GAP that makes the OS problematic to spec in appliances and IoT much less jails. Facilitating security updates and enabling minimal distributions are critical to FreeBSD staying viable as an OS. I say this as a security analyst who spends a large portion of every working day trying to help engineering and operations patch tens of thousands of unnecessarily vulnerability-ridden systems. Roger Marquis