Date: Wed, 6 Aug 2025 16:22:09 -0600 From: Alan Somers <asomers@freebsd.org> To: Mark Johnston <markj@freebsd.org> Cc: freebsd-pkgbase@freebsd.org Subject: Re: freebsd-update and pkgbase Message-ID: <CAOtMX2h5POJYoYeRpuaNL5Yro%2B=OF56bhwkA1i1ym3KZ60W24A@mail.gmail.com> In-Reply-To: <aJPGX9zXE3MeiuhP@nuc>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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. [-- Attachment #2 --] <div dir="ltr"><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Aug 6, 2025 at 3:17 PM Mark Johnston <<a href="mailto:markj@freebsd.org">markj@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The future of freebsd-update post 15.0 isn't totally clear. There have<br> been proposals to remove it in 15.0. IMO we can't remove it outright,<br> since may be needed in order to upgrade 13.x and 14.x jails on a 15.0<br> host. It is also a shame to lose a simple upgrade utility that is<br> well-documented and that many users are familiar with; compare<br> "freebsd-update upgrade -r 14.3-RELEASE" with the upgrade instructions<br> on the pkgbase wiki page.<br> <br> pkgbase offers a lot of flexibility but I suspect many users don't need<br> it; they need a one-shot "upgrade my system, please" utility that will<br> automatically create a boot environment, configure pkg repositories as<br> needed for major/minor/security upgrades, fetch packages, and handle<br> package installation order (i.e., kernel first, followed by a reboot).<br> <br> I don't really think this functionality belongs in pkg itself. So,<br> seeing as freebsd-update already handles some of the above, and users<br> are already familiar with it, I propose extending freebsd-update to work<br> in a pkgbase world. Users would be free to not use it and instead use<br> pkg directly if they so desire, but this would provide a simple<br> alternative to those who don't want or need that flexibility.<br> <br> I'm going to try implementing this, if only to see if there are any<br> unexpected issues that come up. Feedback would be appreciated, both on<br> the proposal itself and on any technical hurdles you see. Aside from<br> the internal changes needed to make freebsd-update subcommands use pkg,<br> I see a few tasks and requirements:<br> - freebsd-update should be able to bootstrap pkgbase; in practice, I<br> think this means that we should import pkgbaseify and make<br> freebsd-update able to run it if the user so requests.<br> - freebsd-update should possibly live in its own pkgbase package so that<br> it can upgrade itself before the rest of the system.<br> - freebsd-update should configure a pkgbase repository using a file in<br> /etc/pkg, disabled by default so that regular "pkg upgrade" doesn't<br> try to touch the base system. I'm not sure yet how repository<br> configurations should be managed: should they be dynamically<br> generated, or should we provide some bundle of configurations (e.g.,<br> one for every supported release), or?<br> - We need to figure out how to handle freebsd-update.conf options which<br> don't make sense in a pkgbase world.<br></blockquote><div><br></div><div>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. </div></div></div>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2h5POJYoYeRpuaNL5Yro%2B=OF56bhwkA1i1ym3KZ60W24A>