Date: Mon, 9 Feb 2026 23:58:55 +0300 From: Vadim Goncharov <vadimnuclight@gmail.com> To: Graham Perrin <grahamperrin@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: FreBSD pkgbase MUST be ebandoned Message-ID: <20260209235855.7de86893@nuclight.lan> In-Reply-To: <aead1402-e403-4b61-943b-0938881d2cde@gmail.com> References: <0iqhe92aheNJohSnhh8-hXkXhQsaRG4D64nLTlTSIPgd6Iit07IwlMwmn-mIS-Qtp9KuZElphybTlYDIVTUDcVGpHWaUbQVGPKt53NSL5Jg=@proton.me> <1678741437.20260206163514@yahoo.com> <07af999d-3c7b-4fe2-8ed2-a37cf89b663b@quip.cz> <20260206230926.50c6afed@nuclight.lan> <aead1402-e403-4b61-943b-0938881d2cde@gmail.com>
index | next in thread | previous in thread | raw e-mail
On Mon, 9 Feb 2026 03:31:04 +0000
Graham Perrin <grahamperrin@gmail.com> 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.
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
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
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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20260209235855.7de86893>