On Fri, Aug 8, 2025, at 7:20 AM, David Chisnall wrote: > On 8 Aug 2025, at 15:02, Santiago Martinez <s...@codenetworks.net> wrote: >> 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?
I don't have to reboot my system after upgrading third-party software. I may have to after updating the base system. Also, when something breaks, it's usually because something changed. If I can compartmentalize the changes, I can better understand what causes an issue. The OS is a bigger, more involved dependency than third-party software. I think about them on different cycles, I want to control them on different cycles. > 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. I think this conflates the mechanism and policy a bit. Before pkgbase, the default freebsd policy is to upgrade base and third-party separately. Perhaps that was an accidental outcome of them using different mechanisms, I don't know. But it's been that way for a long, long time. Thus people talking about POLA. pkgbase introduces a new mechanism for updating base. Now what we're seeing is two camps of what the default policy should be: - camp A says retain the default freebsd policy of updating base and third-party separately - camp B says change the default freebsd policy to updating them all together Hopefully without making things too confusing, I think people are also talking past each other a bit because there's a conflict between the historical policy of base/third-party, and pkg. Because we could also say: - camp A says change the default pkg policy to account for base/third-party separation - camp B says retain the default pkg policy to operate on all packages In short, based on the proposals I've seen here, there's a tension: either retain freebsd default policy and change pkg default policy, or vice versa. Maybe there's a way of resolving the tension, or maybe the project just needs to pick one and move on. >> 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? Same as before: I want to be able to answer, do two versions of third-party software run on a single known version of FreeBSD? Likewise, does one version of third-party software run on multiple known versions of FreeBSD? > 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. That's perfectly reasonable to me. I guess the core question is: why change the established policy of updating base and third-party separately, and require users to use a flag to retain it? Why not retain the policy, and require users to use a flag to update both separately? - Because it's so inherently superior to the old way that it should be the default, and people who want the old way just need to read UPDATING to know the tweaks to make? - Because doing so would make the semantics of `pkg` too confusing? So we accept the tradeoff of changing established upgrade policy, and again people need to be familiar with UPDATING? - Other reasons? pkgbase seems like a fine mechanism for upgrading base. The issue at hand seems to be that the current approach changes the default freebsd upgrade policy in a significant way. Pat
