Re: freebsd-update and pkgbase

On Wed, Aug 6, 2025 at 3:17 PM Mark Johnston <markj@freebsd.org> wrote:

> The future of freebsd-update post 15.0 isn't totally clear.  There have
> been proposals to remove it in 15.0.  IMO we can't remove it outright,
> since may be needed in order to upgrade 13.x and 14.x jails on a 15.0
> host.  It is also a shame to lose a simple upgrade utility that is
> well-documented and that many users are familiar with; compare
> "freebsd-update upgrade -r 14.3-RELEASE" with the upgrade instructions
> on the pkgbase wiki page.
>
> pkgbase offers a lot of flexibility but I suspect many users don't need
> it; they need a one-shot "upgrade my system, please" utility that will
> automatically create a boot environment, configure pkg repositories as
> needed for major/minor/security upgrades, fetch packages, and handle
> package installation order (i.e., kernel first, followed by a reboot).
>
> I don't really think this functionality belongs in pkg itself.  So,
> seeing as freebsd-update already handles some of the above, and users
> are already familiar with it, I propose extending freebsd-update to work
> in a pkgbase world.  Users would be free to not use it and instead use
> pkg directly if they so desire, but this would provide a simple
> alternative to those who don't want or need that flexibility.
>
> I'm going to try implementing this, if only to see if there are any
> unexpected issues that come up.  Feedback would be appreciated, both on
> the proposal itself and on any technical hurdles you see.  Aside from
> the internal changes needed to make freebsd-update subcommands use pkg,
> I see a few tasks and requirements:
> - freebsd-update should be able to bootstrap pkgbase; in practice, I
>   think this means that we should import pkgbaseify and make
>   freebsd-update able to run it if the user so requests.
> - freebsd-update should possibly live in its own pkgbase package so that
>   it can upgrade itself before the rest of the system.
> - freebsd-update should configure a pkgbase repository using a file in
>   /etc/pkg, disabled by default so that regular "pkg upgrade" doesn't
>   try to touch the base system.  I'm not sure yet how repository
>   configurations should be managed: should they be dynamically
>   generated, or should we provide some bundle of configurations (e.g.,
>   one for every supported release), or?
> - We need to figure out how to handle freebsd-update.conf options which
>   don't make sense in a pkgbase world.
>

This sounds like a great idea.  You might consider switching to
freebsd-rustdate, though.  It's far faster and somewhat easier to use.
It's probably more maintainable, too.