Paths

Table of Contentst

packages: Remove set-devel from set-base
AbandonedPublic
Actions

Authored by ivy on Fri, Sep 19, 2:52 PM.

Details

Reviewers

dch
ifreund_freebsdfoundation.org

Group Reviewers

pkgbase
releng

Summary

Remove the dependency from set-base to set-devel, making the two sets
orthogonal. This means base is now "the complete base system without
compilers".

The use case for this is users who want to install the entire runtime
system so that they don't have to worry about whether something is
installed or not, but who don't want compilers installed, which is
common for containers or jails, and for organisations with a policy
of not installing compilers on production systems.

set-base is already not the complete base system (because it doesn't
include tests, lib32, or debug symbols), so this is less of a semantic
change than it might appear. It is a departure from how dist sets work,
but other systems (e.g., NetBSD) already separate compilers from the
base set.

Update the language in bsdinstall, and ensure set-devel is staged on the
release media in pkgbase-stage.lua, since set-base no longer implies it.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 67168
Build 64051: arc lint + arc unit

Event Timeline

ivy created this revision.Fri, Sep 19, 2:52 PM

Herald added subscribers: jrtc27, imp. · View Herald TranscriptFri, Sep 19, 2:52 PM

ivy requested review of this revision.Fri, Sep 19, 2:52 PM

Harbormaster completed remote builds in B67168: Diff 162419.Fri, Sep 19, 2:52 PM

ivy added a reviewer: ifreund_freebsdfoundation.org.Fri, Sep 19, 2:56 PM

portmaster_BSDforge.com added a subscriber: portmaster_BSDforge.com.Fri, Sep 19, 11:20 PM

IMHO this adds additional complication to a new and already fairly complicated change.
IOW We've already learned (have been trained) as to how the dist sets work. It's
intuitive and makes sense. base is base. It's all you need to run your system and
build additional bits as you require. The same for kernels, 32 bit compatibility
and so-on. It appears we'll reach nearly 30 packages if we continue to split
things up. I guess I'm lobbying to try and keep things as close as possible to what
we've come to expect from FreeBSD. Many of us have built tooling around our expectations
and these proposed changes add additional burdens.

In D52621#1202250, @portmaster_BSDforge.com wrote:

It appears we'll reach nearly 30 packages if we continue to split things up.

we will probably add more sets, but those will all be subsets of base, i.e. if you install base you will also get whatever other sets exist. this is how minimal works already: the base set depends on minimal, so you only have to install base and you get minimal as well. if we decided to add a "networking" set (which i'm not planning to do, but just for example), installing "base" would also install "networking".

the only exceptions to this are the things that were already outside the pre-pkgbase base set (src, tests, lib32, dbg, kernel), and this one new set, devel. so the only semantic change here is that whereas previously you installed base, now you install base and devel. that's 1 new set, not 30.

if you want a set which includes both base and devel, i can add that as well, but someone needs to decide what to call these sets, and the name needs to be clear to users. for example, if "base" stays as it is, what should the new "base but without devel" set be called? the only suggestion i've heard so far is "notoolchain", which i really dislike because it doesn't make sense to name sets based on what they don't contain.

In D52621#1202250, @portmaster_BSDforge.com wrote:

. . . It appears we'll reach nearly 30 packages if we continue to split
things up. . . .

Some of this is terminology, such as plain "packages" vs. named "sets of packages" . . .

There are lots of packages but comparatively few sets of packages. There are fewer still of what I'll call here: "installer units".

WARNING: things are changing for the partitioning and the below details are no longer as complete or accurate about FreeBSD-set-* .

Named Sets of Packages (with installer units notes):

FreeBSD-set-base         (optional)
FreeBSD-set-minimal      (FreeBSD-set-base includes this; no way to not select in bsdinstall)
FreeBSD-set-minimal-jail (only selectable if no kernels and then is optional; FreeBSD-set-base includes this)

FreeBSD-set-devel   (optional; this one is still bundled in FreeBSD-set-base --so far)
FreeBSD-set-kernels (optional; not bundled)
FreeBSD-set-lib32   (optional; not bundled)
FreeBSD-set-src     (optional; not bundled)
FreeBSD-set-tests   (optional; not bundled)

(bsdinstall just has a debug option that pairs the matching *.dbg items below to the selections from the above:)
FreeBSD-set-base-dbg
FreeBSD-set-devel-dbg
FreeBSD-set-kernels-dbg
FreeBSD-set-lib32-dbg
FreeBSD-set-minimal-dbg
FreeBSD-set-minimal-jail-dbg

But the count of packages (excluding the above sets) is much larger, such as:

# pkg-static info -C -x '^FreeBSD-' | grep -v ^FreeBSD-set- | wc -l
pkg-static: Warning: Major OS version upgrade detected.  Running "pkg bootstrap -f" recommended
     467

Note: This is for . . .
# uname -apKU
FreeBSD 7950X3D-ZFS 16.0-CURRENT FreeBSD 16.0-CURRENT main-n280461-506b36c4fdde GENERIC-NODEBUG amd64 amd64 1600000 1600000

There used to be over 530 but some have been consolidated.

FreeBSD-base is the name of the repo for all FreeBSD (operating system) packages.

I would not be confused by FreeBSD-set-standard as the name of a meta package. I'd expect the end result to be standard.

Giving mixed meanings to the word base is not a good idea …

i'm not fond of "standard" because it's not really clear what it means. who decides what is the "standard" package set? why is "base" more standard than "minimal"?

"base" is not really great either because it doesn't include all of base, but it's at least consistent with the historical base.txz distribution set.

i am still thinking about this but i really want to land it for 15.0R, and i haven't seen a proposal i prefer yet. i actually think we should have always shipped comp.txz as a separate set like NetBSD does, but we didn't... but it's never too late to fix that!

In D52621#1203868, @ivy wrote:

… who decides …

An ultimate decision on which FreeBSD-* packages are within a FreeBSD-* meta package should (I believe) be made by re@, because re@freebsd.org is explicitly the maintainer.

Re: meta naming, I should probably take the discussion back to freebsd-pkgbase@ https://lists.freebsd.org/archives/freebsd-pkgbase/2025-September/000909.html to help re@ with its ultimate decision-making :)

Thanks

ivy added a reviewer: releng.Thu, Sep 25, 7:19 PM

Ok, I'm going to weigh in with my re@ hat: For 15, what we offer in the installer as "base" should match as closely as possible what ships in the base.txz distset. Doing otherwise poses too much risk of confusion.

In the long term, we should probably just avoid the name "base" except when referring to the FreeBSD-base repository aka the stuff which gets built from the src git tree. But that's a long-term issue, not a change to make in 15.

as discussed on IRC, we'll probably go with a new "optional" set that excludes devel, then base will be optional+devel, which preserves the existing semantic meaning of "base".

ivy abandoned this revision.Sun, Sep 28, 9:27 PM

In D52621#1205738, @ivy wrote:

as discussed on IRC, we'll probably go with a new "optional" set that excludes devel, then base will be optional+devel, which preserves the existing semantic meaning of "base".

Thank you Colin, Lexi. This seems like it might be a tenable arrangement for those of us whom have based our work around the "classic" distribution.