Date: Thu, 2 Apr 2026 11:24:38 -0700 From: Mark Millard <marklmi@yahoo.com> To: freebsd-hackers@freebsd.org, freebsd-pkgbase@freebsd.org, freebsd-pkg@freebsd.org Cc: Karl Denninger <karl@denninger.net> Subject: Re: Uh, what's this? (PKGBASE implication) Message-ID: <e3b78ade-0ee8-43b5-9669-865308e9640a@yahoo.com> In-Reply-To: <7b070db3-9540-41aa-8289-05cc386d3563@denninger.net> References: <ccaab08d-277d-4cc8-bd61-d03959148324@denninger.net> <20260402205415.aa43b756e2b1036ab1fb9b9c@dec.sakura.ne.jp> <7b070db3-9540-41aa-8289-05cc386d3563@denninger.net>
index | next in thread | previous in thread | raw e-mail
[This is basically a forward from freebsd-hackers@ to freebsd-pkgbase@ and freebsd-pkg@ . It seems to report a type of pkg handling problem for both port-packages and base-packages. It has the later reply that goes into more detail than the original message did.] On 4/2/26 09:08, Karl Denninger wrote: > On 4/2/2026 07:54, Tomoaki AOKI wrote: >> On Thu, 2 Apr 2026 07:41:21 -0400 >> Karl Denninger <karl@denninger.net> wrote: >> >>> I did not let this proceed as I really don't feel like having a mess to >>> un-mess.... >>> >>> [root@NewFS /home/karl]# uname -v >>> FreeBSD 14.4-STABLE #31 stable/14-n273840-e5ed09ffd592-dirty: Thu Mar 26 >>> 11:17:07 EDT 2026 >>> root@NewFS.denninger.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC >>> >>> [root@NewFS /home/karl]# pkg upgrade >>> Updating FreeBSD repository catalogue... >>> FreeBSD repository is up to date. >>> Updating FreeBSD-kmods repository catalogue... >>> FreeBSD-kmods repository is up to date. >>> All repositories are up to date. >>> Checking for upgrades (255 candidates): 100% >>> Processing candidates (255 candidates): 100% >>> The following 13 package(s) will be affected (of 0 checked): >>> >>> New packages to be INSTALLED: >>> mysql84-client: 8.4.8 [FreeBSD] >>> >>> Installed packages to be UPGRADED: >>> ffmpeg: 8.0.1_5,1 -> 8.1,1 [FreeBSD] >>> harfbuzz: 13.1.1 -> 13.2.1 [FreeBSD] >>> mpc: 1.3.1_1 -> 1.4.0 [FreeBSD] >>> mysql80-client: 8.0.45 -> 8.0.45_1 [FreeBSD] >>> nmap: 7.98_1 -> 7.99_1 [FreeBSD] >>> openexr: 3.4.5 -> 3.4.8 [FreeBSD] >>> perl5: 5.42.1 -> 5.42.2 [FreeBSD] >>> >>> Installed packages to be REINSTALLED: >>> cacti-php83-1.2.30 [FreeBSD] (direct dependency changed: >>> mysql84-client) >>> libass-0.17.4 [FreeBSD] (direct dependency changed: libunibreak) >>> libv4l-1.23.0_5 [FreeBSD] (direct dependency changed: libudev-devd) >>> libvdpau-1.5 [FreeBSD] (direct dependency changed: libXext) >>> mpfr-4.2.2,1 [FreeBSD] (direct dependency changed: indexinfo) >>> >>> Number of packages to be installed: 1 >>> Number of packages to be upgraded: 7 >>> Number of packages to be reinstalled: 5 >>> >>> The process will require 108 MiB more space. >>> 84 MiB to be downloaded. >>> >>> Proceed with this action? [y/N]: >>> >>> Uh, that's a "no" :-) >>> >>> mysql84-client is going to shove things in the same place as mysql80, >>> which it also wants to upgrade the version of. I also have the server >>> loaded; a prior "upgrade" attempt yesterday wanted to upgrade both of >>> those, but there are also several other dependencies (e.g. php modules) >>> which it DID NOT want to upgrade, and that's a potentially-serious >>> problem, and I'm also concerned about cacti which it wants to touch too. >>> >>> -- >>> Karl Denninger >>> karl@denninger.net >>> /The Market Ticker/ >>> /[S/MIME encrypted email preferred]/ >> See corresponding UPDATING entry dated 20260326. >> Stick with 80 or switch to 84. >> >> https://github.com/freebsd/freebsd-ports/blob/main/UPDATING#L60 >> >> But not sure if DEFAULT_VERSIONS in /etc/make.conf works >> on pre-built pkg upgrades. >> >> I myself don't use mysql (having client installed as an "automatic" >> depencencies of something, though), so not 100% sure it works OK or >> not, switching client alone possibly help. >> >> Client are more depended upon by others compared with server. >> >> Regards. > > Apologizes for the less-than-clear subject line, but this has > implications for PKGBASE which is why I put it here on the list. > > A "back-dependence" such as this, if you approve it, will abort because > the new version of the client (in this case) tries to install into an > existing location for the other version, which is already there and is > not being deleted first, and as a result it fails. That operation is > non-atomic and thus if it hits something that the system needs you got > trouble (particularly if you didn't use bectl/beadm first!) as now you > have part of whatever you updated in place but not all of it, nor does > it roll it all back if any part of the install sequence fails. > > Pkg does not appear to have a good way to deal with this issue, and I > can come up with several instances in the past where a package has had > this issue (in particular when OpenSSL 1.x was in base, newer non-ABI- > compatible version(s) were in ports/packages, and you needed the newer > to compile something, although I've also had it bite me with some php > modules in the past.) If the shared libraries get yanked out from under > an executable (e.g. they're upgraded to a new .so version) then the > other binaries will obviously not run. > > If that hits a "gotta have it" system-level binary then you've got a > broken system. > > I'm not sure there's a good way to deal with this with pkg not having > the capacity to be atomic in what it does -- that is, "all is good or > none commits." > > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ -- === Mark Millard marklmi at yahoo.comhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e3b78ade-0ee8-43b5-9669-865308e9640a>