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
F158045619: D54548.id.diff
Wed, May 27, 9:47 PM
F158015751: D54548.id178187.diff
Wed, May 27, 12:48 PM
Unknown Object (File)
Tue, May 26, 10:28 AM
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
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 73274
Build 70157: 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
103–104

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

224

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.

272–276

Maybe a

#
# Base system packages
#

comment to mirror Legacy distribution tarballs above?

384

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.

390–391

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
224

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.

384

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.

390–391

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.