GhostBSD * Station series and Ports

vimanuelt

Brian post the following:

When it comes to updates, I think the GhostBSD * Station series deserves highlight, but perhaps I'm looking for the GhostBSD seal of approval. And after some consideration I think that could be almost entirely automated.

I suppose it comes down to a Project signature/stamp on the release. Something like a build report.

GhostBSD [Web Info/Doc Link]
Current Version ->  Update Version

base v1 (size) (date)->  v2 (size) (date)
latest v1 (size) (date)-> v2 (size) (date)

Build start date: May 14, 2025
Build attempts: 3
Build date: May 19, 2025
Release date: May 21, 2025

Approved By: Ghost Project 1 - Automatic Release
Notes: Automatic Release Stable

Proceed Y/N _

or human

Approved By: Eric
Notes: Taking a couple weeks to go camping.

Yes, it is a lot to follow. Especially ports. Which invariably leads to the fork/original developments there of whatever it is. I don't believe GhostBSD needs to additionally discuss the overhead of managing ports for the user base, or at least reporting the wins/challenges/blockers of building ports belongs in a the System Updates.

It would be reasonable for Software/Ports Station tool to provide add a recurring git (or gits) /usr/ghostbsd-ports, /usr/{repo}

I wasn't really including ports because packages is probably the best general user perspective to have with system and software updates.

Ports Station could be a very small tool that provides means to enable/disable, set check interval (days) for;

System

ports Y/n, Last Sync, (update)

User

TitleOfRepo /usr/projects/TitleOfRepo (edit)
(add)

I'm now wildly off topic. For me, ports aren't part of an Update Station action until long after they've struggled through build(s) to a shared win.

vimanuelt

First, let us come to a basic understanding of FreeBSD Ports.

FreeBSD’s Ports Collection is maintained as a continuously evolving tree, with commits landing at all times and daily snapshots made available (for example via portsnap) The FreeBSD Forums. There is no single event labelled a “Ports release.” Instead, to offer a stable foundation for binary package users, the Ports Management Team creates a quarterly branch on the first day of January, April, July and October. Those branches accept only updates that fix security issues, resolve bugs or adjust framework elements, avoiding the introduction of new features docs.freebsd.org.

When the FreeBSD release process reaches its final candidate stage, the Release Engineering Team selects whichever quarterly branch is current at that moment for the ports used in the release build. In that way each FreeBSD release draws on a well-defined snapshot of the Ports Collection, even as the main tree continues to advance between quarters docs.freebsd.org.

vimanuelt

One straightforward approach is to establish a regular snapshot schedule for the GhostBSD ports tree and record each snapshot with a precise timestamp in the GhostBSD overlay repository. For example, one might run a weekly cron job (or a GitHub Actions workflow) that updates a local clone of the FreeBSD ports.git mirror, commits any changes into the ghostbsd-ports repository and then immediately tags that commit using the current date and time (for instance “ports-2025-05-21T02:00Z”). In this way every update is both automatically synchronised and uniquely identifiable.

Implementation requires only a small wrapper script. It would begin by fetching from the upstream FreeBSD ports.git, then merge or fast-forward the ghostbsd-ports branch, and finally create an annotated Git tag bearing the timestamp. By pushing both branch and tag back to your central Git server you ensure that every GhostBSD build can reference an exact snapshot of the ports tree. Users or automation pipelines would then pull from these tagged snapshots rather than the rolling master, yielding a reproducible, standardized set of ports.

To integrate with the existing build framework the GhostBSD project can have the build report include the selected ports-tag name. That serves as your serialized standardization stamp. If one prefers coarser granularity one could switch to a weekly or monthly cadence, or even incorporate the FreeBSD quarterly branches as base points. Either way, automating the fetch-commit-tag cycle gives GhostBSD complete control over when ports change in the releases and provides clear auditability through timestamped snapshots.

vimanuelt

I have created a ports script in an early discussion. I have take the ports serialization idea and added it.
https://forums.ghostbsd.org/d/383-a-first-attempt-at-a-ghostbsd-automated-ports-tree-maintenance-script/2

brianthehughes

I don't believe there is sufficient value to expose GhostBSD userbase to ports. I feel that ports are a developer/contributor/advanced user resource and the audience for ports is fractionally insignificant in the GhostBSD userbase, futher in the broad *BSD userbase... packages address the needs/wants of the many - specifically non-dev users.

I have no data to support this perspective, but anecdotally - only devs/contributors/advanced users EVER discuss ports in Telegram.

Following the rolling ports master feels like a hold over from GhostBSD following FreeBSD-STABLE. Adopting quarterly branches would seem to be more inline with GhostBSD leveraging FreeBSD-RELEASE.

As I've come to eagerly anticipate, Vic, your overarching perspective on how ports could be systematically predictable and operationally transparent is reasonable.

My less robust proposal to enable ports (and other repos) is targeting advanced users/devs and assumes an intention of following the rolling master/main. I appreciate the notion of including the branch and tag as this provides a completness I had not considered.

vimanuelt

I am not suggesting that the general user base should be exposed to the FreeBSD and GhostBSD Ports Collections. Rather, I am advocating for GhostBSD to establish predictable and reproducible infrastructure in its handling of ports behind the scenes. This is precisely so that end users do not need to concern themselves with it.

General users should never be expected to manage ports manually. However, the GhostBSD project must manage them deliberately, at least for the purposes of building and curating binary packages. By serializing ports snapshots with timestamped tags and integrating those into build reports, the project can enhance auditability, reproducibility, and rollback, all of which directly benefit the user experience.

The observation that ports are a niche interest among GhostBSD users is probably accurate. However, that does not make the Ports Collection irrelevant. Every package installed via pkg originates from the ports tree. The more consistent and controlled that tree is during the build process, the more stable and predictable the resulting system becomes.