On 8 Aug 2025, at 15:02, Santiago Martinez <s...@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
