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.
