Re: Uh, what's this? (PKGBASE implication)

On 4/2/2026 07:54, Tomoaki AOKI wrote:
> On Thu, 2 Apr 2026 07:41:21 -0400
> Karl Denninger<[email protected]> 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
>> [email protected]:/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
>> [email protected]
>> /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
[email protected]
/The Market Ticker/
/[S/MIME encrypted email preferred]/