From nobody Wed Aug 20 07:48:04 2025 X-Original-To: freebsd-current@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 4c6JVK54Vbz64Xy0; Wed, 20 Aug 2025 07:48:41 +0000 (UTC) (envelope-from bsd.lists@h8spam.org) Received: from mx1.wiredblade.com (mx1.wiredblade.com [162.216.242.35]) (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 4c6JVH6qcPz3ZQN; Wed, 20 Aug 2025 07:48:39 +0000 (UTC) (envelope-from bsd.lists@h8spam.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of bsd.lists@h8spam.org has no SPF policy when checking 162.216.242.35) smtp.mailfrom=bsd.lists@h8spam.org Received: from webmail.dynu.com (webmail.dynu.com [162.216.242.204]) by mx1.wiredblade.com with ESMTPA ; Wed, 20 Aug 2025 07:48:23 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Wed, 20 Aug 2025 07:48:04 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.17.0 From: "Chris" Message-ID: Subject: Re: PKGBASE Removes FreeBSD Base System Feature To: "Miroslav Lachman" <000.fbsd@quip.cz>, "David Chisnall" Cc: "vermaden" , "Shawn Webb" , freebsd-pkgbase@freebsd.org, freebsd-stable@freebsd.org, freebsd-pkg@freebsd.org, freebsd-current@freebsd.org, pete@nomadlogic.org, bapt@freebsd.org, bane@pmf.uns.ac.rs In-Reply-To: <9a03be4d-4621-445c-980d-e63c7f163e78@quip.cz> References: <9a03be4d-4621-445c-980d-e63c7f163e78@quip.cz> X-Originating-IP: 24.113.41.88 X-Spamd-Bar: / X-Spamd-Result: default: False [0.88 / 15.00]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; NEURAL_HAM_LONG(-0.98)[-0.982]; NEURAL_HAM_SHORT(-0.23)[-0.232]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.10)[text/plain]; SUSPICIOUS_AUTH_ORIGIN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:398019, ipnet:162.216.242.0/24, country:US]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; DMARC_NA(0.00)[h8spam.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[interia.pl,hardenedbsd.org,freebsd.org,nomadlogic.org,pmf.uns.ac.rs]; RCPT_COUNT_SEVEN(0.00)[11]; TO_MATCH_ENVRCPT_SOME(0.00)[]; HAS_XOIP(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-pkgbase@freebsd.org,freebsd-stable@freebsd.org,freebsd-pkg@freebsd.org,freebsd-current@freebsd.org]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4c6JVH6qcPz3ZQN August 4, 2025 3:34 PM, "Miroslav Lachman" <000.fbsd@quip.cz> wrote: > On 01/08/2025 16:22, David Chisnall wrote: >=20 >>=20On 31 Jul 2025, at 02:57, Miroslav Lachman <000.fbsd@quip.cz> wrote: >>> I would also like to separate it. Use one command to update (upgrade) >>> 3rd party packages and another to update (upgrade) base packages. It >>> is our workflow for the last 25+ years thus running one command to >>> update both is really unexpected and unwanted. >>=20 >>=20I disagree here. If you *want* to separate them, then you can: you = can >> specify the repository that you want to upgrade explicitly. But if yo= u >> do then you risk things like: >>=20 >>=20- I=E2=80=99ve upgraded my base system, but not my ports-kmods thing= s, so now >> my GUI doesn=E2=80=99t start. >> - I=E2=80=99ve upgraded ports, but the ports tree is built on a newer = point >> release and I need to upgrade to make some symbols exist. >> - I=E2=80=99ve upgraded the base system and now some kmods from ports = don=E2=80=99t work. >>=20 >>=20All of these are things that users have complained about publicly in= the >> last year or so. >>=20 >>=20I have avoided them by always doing `freebsd-update install && pkg >> upgrade` and keeping that in my shell history[1] so I don=E2=80=99t ac= cidentally >> forget to upgrade both together. >>=20 >>=20Given a choice between a thing that works for users, or something th= at >> *can* work for users but comes with a bunch of footguns that they need >> to avoid, I=E2=80=99d pick the former. >>=20 >>=20David >>=20 >>=20[1] I=E2=80=99ve noticed on fresh installs, the default shell no lon= ger has >> working persistent history, which is a *big* POLA violation, if people >> want to complain about something. >=20 >=20I see your point, but our workflow is much different. One command to > upgrade base and packages at the same time is like "one to break it all= " > to me. > I have seen broken "pkg upgrade" so many times... but it never breaks > base and running ssh so I am still able to fix it somehow.. > Running FreeBSD for more than 25 years on tens of machines (headless > servers) and I never need to do upgrade of base and packages at the sam= e > time. I am not saying nobody need it. Yes it can be useful on upgrading > desktops or other installations with kmods, but I think it still can be > done in 2 separate steps to keep the base untouched if user wants it. > Mainly when there is another step needed - etcupdate. Having base and > packages upgraded and only then fixing conflicts with etcupdate seems > very bad idea to me. The biggest problem I see in all this, is that all the drivers were moved= to ports/. That's a HUGE failure. When they existed in $base you had the opt= ion to build only the drivers you needed and you built them with $BASE. So th= ere were never any symbol collisions/mismatches. Moving them to ports has onl= y made the whole procedure more cumbersome and error prone for everyone. Wh= ich makes this whole "how do we categorize/manage this whole pkg-base thing?"= a complete mess w/o a clear or ideal solution. That's my take/experience FWIW. >=20 >=20Kind regards > Miroslav Lachman