Page MenuHomeFreeBSD

release: Improve error handling and option logic
Needs ReviewPublic

Authored by ivy on Jan 6 2026, 1:46 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, May 22, 5:15 PM
Unknown Object (File)
Thu, May 21, 12:30 AM
Unknown Object (File)
Sun, May 17, 5:11 AM
Unknown Object (File)
Sun, May 17, 2:57 AM
Unknown Object (File)
Sat, May 16, 4:22 PM
Unknown Object (File)
Thu, May 14, 6:45 AM
Unknown Object (File)
Tue, Apr 28, 10:59 AM
Unknown Object (File)
Mon, Apr 27, 1:04 PM
Subscribers

Details

Reviewers
None
Group Reviewers
releng
Summary

Based on the user-provided options, define three internal variables,
_USE_PKG, _USE_PKGBASE and _USE_PORTS, to avoid having to repeat the
hard-to-read "!defined(X) || empty(X)" conditional in many places.

Add some early errors for things we know don't work, like using pkg
on non-FreeBSD platforms.

Stop ignoring errors when installing packages onto the media; if this
fails and the user is okay with that, they should set NOPKG to avoid
trying it in the first place. This avoids silently building media
which is missing expected components.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 69643
Build 66526: arc lint + arc unit

Event Timeline

ivy requested review of this revision.Jan 6 2026, 1:46 AM

This seems like a good idea to me; will take a detailed look soon. Patch needs to be rebased.

This seems like a good idea to me; will take a detailed look soon. Patch needs to be rebased.

this entire stack is stalled until we can get some consensus on D54282. i'm working on other pkgbase things in the mean time.

release/Makefile
95–96

probably worth being explicit about _USE_PKG referring to pkg(8), since it seems _USE_PKG and NOPKG ought to be related.

214

I think it was originally intentional to have only the dependencies in the conditional, but I guess this will be clearer for when distset support is eventually removed.

263–264

Maybe a

#
# Base system packages
#

comment to mirror Legacy distribution tarballs above?

360

This is not necessarily true is it? Can the user set both NODISTSETS and NOPKGBASE (to produce a mostly useless installer)?

Or, is this just intended to explain why we're copying the MANIFEST even if building pkgbase installer? The comment a few lines below (Copy MANIFEST to provide legacy dist checksums in both modes) was intended to indicate that, but is admittedly terse.

Maybe just Even if we're building pkgbase media... and then remove the terse comment below.

368–369

This precludes us producing an installer with both pkgbase packages and dist sets that allows the user to choose either from the media. We'll likely get there (and remove dist set logic altogether) but we might not want to do it yet?

ivy marked an inline comment as done.

rf

release/Makefile
214

i don't think there's any point defining the target if it's not going to be used; this prevents something depending on it by accident.

360

i don't think this comment was really explaining anything, so i've just removed it.

setting both NODISTSETS and NOPKGBASE would probably fail to build, since these targets assume we're building at least one of them.

368–369

This precludes us producing an installer with both pkgbase packages and dist sets that allows the user to choose either from the media.

yes, but it already worked like this. i don't think we even have room for both on disc1, do we? that's why the dist sets are only on dvd1.