Re: FreBSD pkgbase MUST be ebandoned

On Mon, 9 Feb 2026 14:35:19 -0800
Mark Millard <[email protected]> wrote:

> On 2/9/26 12:58, Vadim Goncharov wrote:
> > On Mon, 9 Feb 2026 03:31:04 +0000
> > Graham Perrin <[email protected]> wrote:
> >   
> >> On 06/02/2026 20:09, Vadim Goncharov wrote:  
> >>> … Goung to pkgbase as it is designed currently is a way to have all
> >>> problems of Linux distros upgrades known for decades.    
> >>
> >> Please, don't conflate.  
> > 
> > Huh, where? This is absolutely the same approach "everything is a package,
> > managed by same utility".
> >   
> >>> As pkg regularly fuckups even with ports, it will be more serious with
> >>> base. …    
> >>
> >>
> >> I think not.  
> > 
> > Your "think" is not backed by any evidence. I, however, regularly see
> > problems with pkg(8), for example, freshest was my desktop's update month
> > ago after which every pkg invocation gives bunch of:
> > 
> > pkg: glib-bootstrap: duplicate dependency listing: python311
> > pkg: glib-bootstrap: duplicate dependency listing: python311
> > pkg: glib: duplicate dependency listing: python311
> > pkg: libdbusmenu: duplicate dependency listing: python311
> > pkg: libdbusmenu: duplicate dependency listing: python311
> > pkg: gtk3: duplicate dependency listing: python311
> > pkg: py311-evdev: duplicate dependency listing: python311
> > pkg: py311-evdev: duplicate dependency listing: python311
> > pkg: libwacom: duplicate dependency listing: python311
> > pkg: libwacom: duplicate dependency listing: python311
> > pkg: libinput: duplicate dependency listing: python311
> > pkg: libinput: duplicate dependency listing: python311
> > pkg: py311-lz4: duplicate dependency listing: python311
> > [...]
> > 
> > While I was said there was some problems at cluster exactly at start of
> > January "and fix will be mirrored in a day-two", nothing was recovered by
> > itself. OK, those above are looking harmless (pkg seems to work) and I
> > could dig into code and SQLite and try to fix them, but that is not for
> > ordinary user.  
> 
> Note: My notes have a rather limited intended range-of-issues coverage,
> not grand scale conclusions.
> 
> 
> If would seem that there are 2 basic possibilities:
> 
> ) pkg itself created the duplication and so those are effectively
> notices of internal problems
> 
> vs.
> 
> ) pkg is reporting oddities in ports or ports infrastructure results
> that it was told to process to produce packages from: External
> misconfiguration instead?
> 
> I do not see any evidence of which it is.
> 
> I also do not see any evidence that the configuration control that
> FreeBSD supplies to pkg to produce base-packages were in any way
> involved for the above: it might not be a pkgbase-specific problem at all.

Yes, this is not from pkgbase, this is from home 13.5 desktop updating at
beginning of January from 2025Q1 to 2025Q4 (also using Synth). I was told
something bad happened on cluster that time "and fix should be available on
mirrors in a day", but seems that was another issue, as I'm still getting
those. Of course, I can dig into pkg(8) sources and find the problem, but this
is not what ordinary user can do (and I also did not have enough time for
this).
That is, I just of show this as a symptome of pkg(8) mediocre quality:
it stumbles on level ground. This is unacceptable in critical parts which base
system is - it is tolerabel in ports exactly because you have base system with
which in worst case you can delete /usrl/local and start with fresh pkg.

> > 
> > Another case I was seeing is complains in January in local-language
> > Telegram chat about pkgbase - something was repackaged, and man struggled
> > with it for many days. His English is poor so he did not file beug report,
> > and this again shows unreadyness of pkgbase - I expect vast majority of
> > users to have problems with it delayed till FreeBSD 16 - anyone had
> > functional tests for pkg for this case already? No? Quite expectable.
> > 
> > Another case I've in same chat from same man today:
> > 
> > 
> > Installed packages to be REMOVED:
> >         pkg: 2.0.6  
> 
> Hmm. Looking:
> 
> . . .
> ports-mgmt/pkg: udpate to 2.0.5 : committed 2025-01-28 08:31:10 +0000
> ports-mgmt/pkg: update to 2.0.6 : committed 2025-02-11 13:47:12 +0000
> ports-mgmt/pkg: update to 2.1.0 : committed 2025-03-28 07:39:45 +0000
> . . .
> ports-mgmt/pkg: update to 2.5.1 : committed 2025-12-23 10:29:24 +0000
> 
> Now: 2026-Feb-09 (UTC)
> 
> So: pkg 2.0.6 was in-development software from about a year ago when it
> was being replaced recently, as reported above.

Huh, pkg is *always* in-development software. It always wants to update itself
and do not have stable branches.

> (Note: The FreeBSD OS configuration control of and execution of pkg for
> building base-packages is not part of pkg itself but is instead part of
> FreeBSD OS.)
> 
> Also, "pkgbase - something was repackaged" is a matter of the FreeBSD
> configuration control and use of pkg to have it produce base-packages,
> not directly of the pkg executable. A similar point goes for repackaging
> of port-packages.

This does not matter to end user for overall effect.

> > Number of packages to be removed: 1
> > Number of packages to be installed: 51
> > Number of packages to be upgraded: 348
> > 
> > The operation will free 1 GiB.
> > 
> > Proceed with this action? [y/N]: y
> > Child process pid=16021 terminated abnormally: Segmentation fault  
> 
> If I understand what is reported correctly, that is from the year old
> 2.0.6 not handling its own self-delete/replacement correctly, something
> that was worked on later in the development.
> 
> Again it is unclear if any base package configuration control by the
> FreeBSD OS was involved.
> 
> My guess is that it would be better to reference "pkg" without trying to
> implicate the part of the FreeBSD OS that runs pkg configured to produce
> base-packages vs. the use by the ports infrastructure for producing
> port-packages --unless one can point to the configuration control
> information that pkg was given.

Again, it doesn't matter to end user upgrading old system. And I am, as
another user, seeing such reports, draw a conclusion that using pkg(8) for
base is simply too dangerous for my systems.

> > Guess what state system now had, haha! And what's if it pkgbase?
> > 
> > The quality of pkg is poor (as overall quality of ports is lower than
> > base), but still it always was "acceptable" exactly because base system:
> > * is in existence
> > * is distinct from packages
> > 
> > i.e. even in catastrophic event you could recover by just deleting
> > /usr/local and /var/db/pkg starting like a "fresh" install. With pkgbase
> > there will be *NO* such safe ground.
> > 
> > So, the pkgbase project, as it is in it's current form, MUST be abandoned
> > (yeah, in a sense by RFC 2119) and something much serious and
> > mission-critical should be made instead. That is, by Murphy's laws, with
> > primary focus on what can happen bad and thus how to deal with it, instead
> > of childish "oh, we have working code, let's just use it".


-- 
WBR, @nuclight