Re: freebsd-update and pkgbase

From: Vadim Goncharov <vadimnuclight_at_gmail.com>
Date: Tue, 26 Aug 2025 09:04:35 UTC
On Tue, 26 Aug 2025 09:24:39 +0200
Baptiste Daroussin <bapt@freebsd.org> wrote:

> On Wed 20 Aug 01:15, Vadim Goncharov wrote:
> > On Tue, 19 Aug 2025 12:02:20 -0400
> > Mark Johnston <markj@freebsd.org> wrote:
> >   
> > > Adding freebsd-arch@ and re@ to see if anyone not on -pkgbase has
> > > opinions here.
> > > 
> > > On Wed, Aug 06, 2025 at 05:17:19PM -0400, Mark Johnston 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).
> > > >  
> > 
> > Of course. As was said earlier, the whole pkgbase idea in it's current
> > form is harmful, leading to unexpected breakages etc. after mass
> > deployment, not mentioning not very good quality of pkg itself.  
> 
> About pkg quality, there is a way to improve that: report issues, contribute
> code, contribute unit tests etc.

I usually report to local language chat where Vsevolod presents. Doubt if it
goes further, and usually hear complains from other users in same chat.
Majority of users don't go to official reporting channels.

And, "way to improve" does not mean it's already improved enough to be enough
for requirements of base system.

> > The whole distinction between base and ports (packages) is (was) major
> > FreeBSD strength, compared to Linux distros or just plain "zfs delete
> > /usr/local" if something goes wrong.
> > 
> > May be freebsd-update will be redone to be just a frontend to pkg, may be
> > some other way, but the whole wall between base and ports must continue to
> > exist.
> > I think it probably should be even special fork of pkg(8) for pkgbase,
> > just as private (renamed) versions of some ports libraries exist in the
> > base (like sqlite or expat).  
> sqlite is made to be bundled, in particular we are carefully cherrypicking
> features, as for expat, pkg does not use expat at all for years (removed in
> 2020).

This is not about what pkg uses but about usage pattern of libraries in base
system. The presumed pkgbase tool should be like them, because upstream pkg
tool is changing too fast - unaccepatble for Long-Term Support like our entire
major branches are.


-- 
WBR, @nuclight