From nobody Sat Aug 9 19:06:25 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 4bzr4c55nPz649DK; Sat, 09 Aug 2025 19:07:28 +0000 (UTC) (envelope-from pat@patmaddox.com) Received: from fhigh-a1-smtp.messagingengine.com (fhigh-a1-smtp.messagingengine.com [103.168.172.152]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4bzr4b3GK2z4722; Sat, 09 Aug 2025 19:07:27 +0000 (UTC) (envelope-from pat@patmaddox.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=patmaddox.com header.s=fm2 header.b=hug6Mbl+; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="U F7/+gd"; spf=pass (mx1.freebsd.org: domain of pat@patmaddox.com designates 103.168.172.152 as permitted sender) smtp.mailfrom=pat@patmaddox.com; dmarc=pass (policy=none) header.from=patmaddox.com Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.phl.internal (Postfix) with ESMTP id 467D314005CF; Sat, 9 Aug 2025 15:07:26 -0400 (EDT) Received: from phl-imap-15 ([10.202.2.104]) by phl-compute-06.internal (MEProxy); Sat, 09 Aug 2025 15:07:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=patmaddox.com; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm2; t=1754766446; x=1754852846; bh=hHKOGuL7ISsIX7d8weiYEPaeiuzkJL7M 1aSHgUFOiIE=; b=hug6Mbl+r2cNnNIHBdwCo9ijNkmrrYqTwPgK3rBMCBpHkioQ nG1xQWo0M+JATIw4ZoZiHyJ0Tn9BjKfCSwreXHgclLGAoDlk14haPZRJoZn1ZqgO ugWl16yM0BwmD7dKH20EmW4a9IJAVdaf9qkKNDhezkcZ2JSmRbgH/vOH5EsDObtd YqwOh4vVhFmSTpMKCzd/HWBpnkBq5mzhoxPZ+YlD2RNoAikgsH9WlYc594dCU3Sg BZKMr6slEWKENv+p9mDqChGB79M/pMOTFUxVgpoY3jaDZ+Vx+NbfsOHD0Z79HNP9 CEV8LJzdFLzparGL5ZhTocEQJgtRmFVyPNGPCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1754766446; x= 1754852846; bh=hHKOGuL7ISsIX7d8weiYEPaeiuzkJL7M1aSHgUFOiIE=; b=U F7/+gd04/Bip1T0deMvIlwkRx24esj+LQGBmxlYzZT4gQDs57g3QBSYMXVIKMRlQ B4I7hptMF1eUoJFanx0FxW8iDGH/Fwr4THVNTrmiGxsV4WYybHPFsQRqc9g2OhEu 9uHytfc2hygMgilwFwoLCzZt+tJvBnQnwYvXmXuKw+S4pBB7up9o3+CeyWzxCaSn 00+v4+QlJO1snyYJBMX8q/+v3PUJvijaxBOOE7JYFv4nca8mS4CKizJjnk+JuV4A xJIZ5F3QD6yIN7MW8VqLToDuBrZD7CPaZK2gR1yzuA2oNTDtI8Kd9pY7YEhLsaN7 BBLHn/xP35fiJbuteZ8JQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdduvdejgeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgfgsehtqhertdertdejnecuhfhrohhmpedfrfgrthcu ofgrugguohigfdcuoehprghtsehprghtmhgrugguohigrdgtohhmqeenucggtffrrghtth gvrhhnpedtteetueejtdelffejveeutdegffdvvefhffevudeigeelgfetvdetvdevleej vdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehprg htsehprghtmhgrugguohigrdgtohhmpdhnsggprhgtphhtthhopeejpdhmohguvgepshhm thhpohhuthdprhgtphhtthhopehsmhestghouggvnhgvthifohhrkhhsrdhnvghtpdhrtg hpthhtohepfhhrvggvsghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrghdprhgt phhtthhopehfrhgvvggsshguqdhpkhhgsggrshgvsehfrhgvvggsshgurdhorhhgpdhrtg hpthhtohepfhhrvggvsghsugdqshhtrggslhgvsehfrhgvvggsshgurdhorhhgpdhrtghp thhtohepthhhvghrrghvvghnsehfrhgvvggsshgurdhorhhgpdhrtghpthhtohepvhgvrh hmrgguvghnsehinhhtvghrihgrrdhplhdprhgtphhtthhopehfrhgvvggsshguqdgtuhhr rhgvnhhtqdhfrhgvvggsshguqdhorhhgudduudeskhgvthgrshdrshhirdhprhhirdgvvg X-ME-Proxy: Feedback-ID: i8b6c40f9:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id ECA967840B0; Sat, 9 Aug 2025 15:07:24 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface 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 X-ThreadId: T3e9ca0f36eb84e30 Date: Sat, 09 Aug 2025 12:06:25 -0700 From: "Pat Maddox" To: "David Chisnall" , "Santiago Martinez" Cc: vermaden , "Sulev-Madis Silber" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-pkgbase@freebsd.org Message-Id: <5468c172-359f-4cdc-b142-7be1a5d70f16@app.fastmail.com> In-Reply-To: <7D0CD326-0CB0-41F0-99C2-BFEB9F4DC1EA@FreeBSD.org> References: <79429D6B-7948-4D27-9F14-664CC075547A@FreeBSD.org> <7D0CD326-0CB0-41F0-99C2-BFEB9F4DC1EA@FreeBSD.org> Subject: Re: PKGBASE Removes FreeBSD Base System Feature Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-4.03 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.938]; DMARC_POLICY_ALLOW(-0.50)[patmaddox.com,none]; R_DKIM_ALLOW(-0.20)[patmaddox.com:s=fm2,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.152:from]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; ASN(0.00)[asn:151847, ipnet:103.168.172.0/24, country:AU]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[pat]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-pkgbase@freebsd.org,freebsd-stable@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[interia.pl,ketas.si.pri.ee,freebsd.org]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[patmaddox.com:+,messagingengine.com:+] X-Rspamd-Queue-Id: 4bzr4b3GK2z4722 X-Spamd-Bar: ---- On Fri, Aug 8, 2025, at 7:20 AM, David Chisnall wrote: > On 8 Aug 2025, at 15:02, Santiago Martinez wrote: >> This is the same we have today. No extra complexity or confusion, act= ually it is quite simple , if you want to touch your base system just ex= plicitly targeting it ( what we do today with FreeBSD-update) > > What is the reason that you would want to install updates for packages=20 > built by ports and *not* want to install updates to the base system? I don't have to reboot my system after upgrading third-party software. I= may have to after updating the base system. Also, when something breaks, it's usually because something changed. If = I can compartmentalize the changes, I can better understand what causes = an issue. The OS is a bigger, more involved dependency than third-party software. = I think about them on different cycles, I want to control them on differ= ent cycles. > Currently, you need to do these separately because they are managed by=20 > two separate tools, but that=E2=80=99s an accident. It was never a de= liberate=20 > usability choice to have different ways of updating different parts of=20 > the system. Fixing this is one of the goals of pkgbase. I think this conflates the mechanism and policy a bit. Before pkgbase, the default freebsd policy is to upgrade base and third-= party separately. Perhaps that was an accidental outcome of them using d= ifferent mechanisms, I don't know. But it's been that way for a long, lo= ng time. Thus people talking about POLA. pkgbase introduces a new mechanism for updating base. Now what we're see= ing is two camps of what the default policy should be: - camp A says retain the default freebsd policy of updating base and thi= rd-party separately - camp B says change the default freebsd policy to updating them all tog= ether Hopefully without making things too confusing, I think people are also t= alking past each other a bit because there's a conflict between the hist= orical policy of base/third-party, and pkg. Because we could also say: - camp A says change the default pkg policy to account for base/third-pa= rty separation - camp B says retain the default pkg policy to operate on all packages In short, based on the proposals I've seen here, there's a tension: eith= er retain freebsd default policy and change pkg default policy, or vice = versa. Maybe there's a way of resolving the tension, or maybe the projec= t just needs to pick one and move on. >> Nothing stops the user from upgrading base (target base) then upgradi= ng the rest. Or to have a target that is =E2=80=9Call=E2=80=9D. > > This is still possible with pkgbase. If you want to stage things,=20 > simply use the `-r` flag. But when do you *actively want* that? Same as before: I want to be able to answer, do two versions of third-pa= rty software run on a single known version of FreeBSD? Likewise, does on= e version of third-party software run on multiple known versions of Free= BSD? > Every upgrade flow I have on every FreeBSD machine I use is simplified=20 > by pkgbase. Having fewer tools is a usability win. Having a single=20 > command upgrade everything is a usability win. If you *want to*=20 > upgrade only some things, that=E2=80=99s one extra command-line flag. That's perfectly reasonable to me. I guess the core question is: why change the established policy of updat= ing base and third-party separately, and require users to use a flag to = retain it? Why not retain the policy, and require users to use a flag to= update both separately? - Because it's so inherently superior to the old way that it should be t= he default, and people who want the old way just need to read UPDATING t= o know the tweaks to make? - Because doing so would make the semantics of `pkg` too confusing? So w= e accept the tradeoff of changing established upgrade policy, and again = people need to be familiar with UPDATING? - Other reasons? pkgbase seems like a fine mechanism for upgrading base. The issue at han= d seems to be that the current approach changes the default freebsd upgr= ade policy in a significant way. Pat