Re: PKGBASE Removes FreeBSD Base System Feature

On 8 Aug 2025, at 15:02, Santiago Martinez <sm@codenetworks.net> wrote:
> 
> Hi David, I see your point.
> 
> For me, no pkg command (upgrade / install : delete / lock) should act on base without the user explicitly targeting base.

Why?

> This is the same we have today. No extra complexity or confusion, actually it is quite simple , if you want to touch your base system just explicitly targeting it ( what we do today with FreeBSD-update)

What is the reason that you would want to install updates for packages built by ports and *not* want to install updates to the base system?

Currently, you need to do these separately because they are managed by two separate tools, but that’s an accident.  It was never a deliberate usability choice to have different ways of updating different parts of the system.  Fixing this is one of the goals of pkgbase.

> Regarding the non-base package dependencies with base, it will be also the same as today. If this is something we are looking to get rid of then is a different situation.

Fixing this is one of the benefits of pkgbase: there is a single upgrade command, unless you explicitly restrict what it is updating (via -r) then it will upgrade everything that is out of date.

> Nothing stops the user from upgrading base (target base) then upgrading the rest. Or to have a target that is “all”.

This is still possible with pkgbase.  If you want to stage things, simply use the `-r` flag.  But when do you *actively want* that?  

> I think most of the FreeBSD user like the separation of base and non base and the current status seems to get rid of it.  Hence some of us are putting attention to it ( maybe too much)

This is a gross mischaracterisation driven by Vermaden’s love of hyperbole.

No one is removing the distinction between the base system and ports.  The base system remains:

 - The thing installed in /, not in /usr/local (or whatever else you put in $LOCALBASE when you build the ports).
 - A uniform set of things maintained by the project.
 - The set of things with stable ABI guarantees during a major release.
 - A self-contained set of things with no external dependencies.
 - A set of things with a support lifecycle maintained by the FreeBSD Release Engineering team.

Every single one of these properties (and probably others I haven’t thought of) are preserved.  The only difference is that upgrades are simpler because I have a uniform tool that manages all of the things that the FreeBSD project distributes (and other things that other people distribute as package repos).

Every upgrade flow I have on every FreeBSD machine I use is simplified by pkgbase.  Having fewer tools is a usability win.  Having a single command upgrade everything is a usability win.  If you *want to* upgrade only some things, that’s one extra command-line flag.

David