From nobody Sun Feb 8 12:05:07 2026 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 4f861J5Pnnz6Rcth for ; Sun, 08 Feb 2026 12:03:48 +0000 (UTC) (envelope-from vimanuelt@fastmail.fm) Received: from fout-b7-smtp.messagingengine.com (fout-b7-smtp.messagingengine.com [202.12.124.150]) (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 4f861H74hmz3Bxd for ; Sun, 08 Feb 2026 12:03:47 +0000 (UTC) (envelope-from vimanuelt@fastmail.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=fastmail.fm header.s=fm3 header.b=HMXE+tPO; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="R v3XEw6"; dmarc=pass (policy=none) header.from=fastmail.fm; spf=pass (mx1.freebsd.org: domain of vimanuelt@fastmail.fm designates 202.12.124.150 as permitted sender) smtp.mailfrom=vimanuelt@fastmail.fm Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfout.stl.internal (Postfix) with ESMTP id BBC961D000B2; Sun, 8 Feb 2026 07:03:46 -0500 (EST) Received: from phl-imap-01 ([10.202.2.91]) by phl-compute-02.internal (MEProxy); Sun, 08 Feb 2026 07:03:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; 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=fm3; t=1770552226; x=1770638626; bh=c9oqSQAjth9ZbL/hF4ruqd3fqCtllMTwQ0YIHPgpAL8=; b= HMXE+tPOda57McU5NYReZ2XSOvktC2qahQd+lPRbkfsXe5Vu8Arb4SarMW/gcrNt cgT4KapxFEldr/g9rxk59h7jwrB27Jm3Ky1Rt8xMY3IoiYxTLIWoPigtvL814zmW DXaqy60SF+8Dz5k0tmkZTACgUxwS41s1RUef4Dd6Rw5UoAra4WbUtHdwc1OrK4t2 VZioPSCr94lDuTzdr1GOqjkmMRV7UZ7RhsNxkNdu+9VVgFlBE3YwhoJa9HqnEJBz 1BGGlUVTt3QYEH0nLMtViu7zlaMzEvoXhVauY2Qj4n/67RcK8RxmmzwgsFIGLFe5 +LqLXTf7UcxEuSgq4tK5dA== 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=1770552226; x= 1770638626; bh=c9oqSQAjth9ZbL/hF4ruqd3fqCtllMTwQ0YIHPgpAL8=; b=R v3XEw6mvodiO3AcSq8heQNU+QnwaUaTD1JKn2OPwJdf4NSqBrdJ5qXwR0Cnhpst/ 3VmMpyB8ddej0Swq5fc5PCq0vJ7NMH2OpLBPiF8EMzwWjjABFI73NQNVZ92po92L DiSFlSIkSIVZ2zd+MSq0fS06YO8hdjDBahlcqiv51iQBruhn+JeKU33wPV2tK6OR dNrBnAeQ9YynKrK3Pp9xHy6VsPnqx9vxL7Ivn9r/5A5pI3vgSEg/e561zp5Gq+oN qQQF0Oxyov+HtHZLEGvXmgx6KRlLPPioUzar0mVhIE0GaU4JWgiHvf66iesSUzAS UJ2Oddjs4tfViCfFLvPgw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdduleefkeekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpefoggffhffvvefkjghfufgtgfesthhqre dtredtjeenucfhrhhomhepvhhimhgrnhhuvghlthcuoehvihhmrghnuhgvlhhtsehfrghs thhmrghilhdrfhhmqeenucggtffrrghtthgvrhhnpedtvdettefgieetgfefteefieehie ehgefgiefgveffvdduleelgeektedtfeefkeenucffohhmrghinhepghhithhhuhgsrdgt ohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvh himhgrnhhuvghlthesfhgrshhtmhgrihhlrdhfmhdpnhgspghrtghpthhtohepvddpmhho uggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsugdqphhkghgsrghsvgesfh hrvggvsghsugdrohhrghdprhgtphhtthhopehhgegtkhgvvgesphhrohhtohhnrdhmvg X-ME-Proxy: Feedback-ID: if8e14258:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 6A1BA18C0067; Sun, 8 Feb 2026 07:03:46 -0500 (EST) 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: AXmonOnAhB2k Date: Sun, 08 Feb 2026 21:05:07 +0900 From: vimanuelt To: hackee Cc: "freebsd-pkgbase@freebsd.org" Message-Id: <7ed57840-2d6e-4032-a012-e36081223c16@app.fastmail.com> In-Reply-To: References: <2e96a48c-b4e7-47d9-b1b7-bfc3ce789664@app.fastmail.com> Subject: Re: FreBSD pkgbase vs distsets. Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-4.08 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; DMARC_POLICY_ALLOW(-0.50)[fastmail.fm,none]; R_DKIM_ALLOW(-0.20)[fastmail.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.150:from]; XM_UA_NO_VERSION(0.01)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[fastmail.fm]; TO_DN_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim,fastmail.fm:dkim]; FREEMAIL_ENVFROM(0.00)[fastmail.fm]; ASN(0.00)[asn:151847, ipnet:202.12.124.0/24, country:AU]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-pkgbase@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[fastmail.fm:+,messagingengine.com:+] X-Rspamd-Queue-Id: 4f861H74hmz3Bxd X-Spamd-Bar: ---- Hi Sergei, Thank you for the clarification. That helps a lot, and I think your conc= ern is entirely reasonable. I do not know what others think about it yet= , but I believe a third option is important to consider carefully. My wo= rk in this area is independent of the FreeBSD Core Team and the FreeBSD = Foundation. I believe the community wants a future where FreeBSD is reproducible and= can be fully independent of FreeBSD project infrastructure in practice. I agree that building distsets from source is not just a historical path= , but a valid architectural choice. In your case, the distset build logi= c is already integrated into your project. It produces staged filesystem= s that are then wrapped into an ISO. Removing this path does not simply = encourage a different workflow. It forces downstream builders to redesig= n their systems and absorb significant rework. There is also an important environmental distinction. A distset based bu= ild is self contained. It relies only on the FreeBSD source tree and bui= ld system. A pkgbase build, by contrast, introduces a dependency on pkg = tooling and ports infrastructure just to manufacture base artifacts, eve= n when ports are otherwise unused. For clean, minimal build environments= , that added surface area is a real cost. >From a tooling perspective, there is room for higher level systems to co= exist with distsets rather than replace them. For example, an artifact o= riented builder can drive the FreeBSD source build, stage the results de= terministically, and emit distsets as outputs. In that model, distsets r= emain the stable interface, while tooling sits above them as an optional= orchestration layer. This preserves existing pipelines while allowing e= xperimentation and evolution. So my request is not to reject pkgbase, but to keep the distsets from so= urce path viable and supported. It serves builders who value minimalism,= determinism, and self contained pipelines, and it avoids imposing unnec= essary dependencies on projects that already have working systems built = around distsets. Best regards, Vester =E2=80=9CVic=E2=80=9D Thacker On Sat, Feb 7, 2026, at 20:58, hackee wrote: > Hi Vester. > > Thanks for your reply. Please consider at least the possibility=20 > building dissets from source, as the packages only provide default=20 > options that you will have to use whether you want to or not. > At the moment I'm using the code present in Makefiles which allows=20 > dissets to be assembled and packaged and placed into a filesystem whic= h=20 > is then wrapped into an ISO image. If this code is removed, I will hav= e=20 > to spend a lot of time redoing much of my project's code. Additionally=20 > distsets building scenario is self-contained, while building base with=20 > pkgbase requires ports, e.i. /usr/ports/ports-mgmt/pkg (with thousands=20 > of files) which I don't need/use, at least in my building environment. > BR, > Sergei. > > > =D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 7 =D1=84=D0=B5=D0=B2=D1=80= =D0=B0=D0=BB=D1=8F 2026 =D0=B3., 1:40 =D0=94=D0=9F, vimanuelt =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > >> As an aside, as FreeBSD moves away from packagesets and toward pkgbas= e, it may be useful to consider whether there are other directions that = could complement this transition without committing the base system to a= single distribution model. >>=20 >> Packagesets were introduced to help administrators reason about the b= ase system as a coherent whole, to control upgrade scope, and to avoid p= artial or inconsistent updates. The underlying issue they addressed was = not packaging itself, but the difficulty of maintaining a clear and stab= le system boundary in a mutable environment. >>=20 >> One possible alternative is to treat the base system as a set of immu= table, versioned artifacts rather than as a mutable collection of packag= es. In such a model, the base OS would be built, published, and consumed= as a coherent unit with a stable identity. Updates would involve switch= ing between known system states instead of incrementally modifying a liv= e environment. This shifts consistency checks to build and publication t= ime rather than upgrade time, and largely avoids the class of problems t= hat packagesets were designed to mitigate. >>=20 >> This approach aligns with several long-standing FreeBSD values, inclu= ding reproducibility, explicit interfaces, and administrative clarity. I= t may also reduce upgrade risk and make rollback and recovery easier to = reason about. Importantly, it would not replace pkg or ports. Instead, i= t would clarify their role by keeping them outside the base system bound= ary, where flexibility and change are expected and acceptable. >>=20 >> Pkgbase already moves toward better base system lifecycle management = within a package-oriented framework. An artifact-oriented perspective co= uld be seen as a further step, changing the upgrade semantics rather tha= n refining them. It does not recreate packagesets, but it may make their= original purpose largely unnecessary by eliminating partial base system= updates altogether. >>=20 >> Whether this is desirable is an open question. It depends on whether = FreeBSD wishes to continue supporting fine-grained, in-place mutation of= the base system, or whether it is worth exploring a model where the bas= e system is something you select, verify, and replace as a whole. >>=20 >> These are questions I am exploring and evaluating using prototypes. >>=20 >> Best regards, >> Vester "Vic" Thacker >>=20 >>=20 >> On Fri, Feb 6, 2026, at 19:22, hackee wrote: >>=20 >> > Hello guys! >> >=20 >> > As far as I understand, FreeBSD 16 is planned to drop distsets supp= ort >> > and move entirely to pkgbase. I am writing to ask you to reconsider >> > this decision. >> > I maintain a small FreeBSD-based project for my own hardware ( for >> > amd64 platform, code can be seen here: >> > https://github.com/h4ckee/CoreBSD ), that depends heavily on distse= ts, >> > and migrating it to a pkgbase-only model would be highly inconvenie= nt. >> > I build custom compact ISO image based on that code. My equipment is >> > for personal use, laptops and a server, but I'm hoping to create a >> > small storage solution based on the compact FreeBSD distribution and >> > may use it on my employer's equipment. There are also other compani= es >> > and projects that use FreeBSD to build their own distributions=E2=80= =94such as >> > appliances and embedded systems=E2=80=94that similarly rely on dist= sets. I >> > would like to propose keeping distsets intact while continuing to o= ffer >> > pkgbase as an alternative for those who wish to use it, in the same= way >> > it is done in the FreeBSD 15 release. I hope you will consider this >> > request favorably. >> >=20 >> > Best regards, >> > Tech. Eng. Sergei Praskovin.