pkg upgrade says "ABI changed"... why would this happen, what does it mean, what (if anything) do I do

[rwv37]

I should start off by saying that I understand that the "ABI" is an interface to low-level code, which might change for example when you upgrade to a new version of the OS, but that's all I really know about it. With that said:

The immediate symptom is that today pkg upgrade told me the following (among a bunch of other stuff that I find more typical):

Installed packages to be REINSTALLED:
        terminfo-db-20231209 (ABI changed: 'FreeBSD:14:amd64' -> 'FreeBSD:14:*')

I don't know why that would have happened, nor what I should do about it (if anything).

Further info about recent proceedings that may or may not be relevant:

I have a nightly script to update /usr/ports and such and then run Synth to build everything. The script does NOT upgrade/install anything - it just builds for my local package repository, and I typically upgrade my machine from that the next day or so, manually. For the past few days, it has been failing to build security/vault, complaining about certificates that could not be verified when trying to download go modules (from https://proxy.golang.org/).

I opened up an issue on Bugzilla about it. One person asked me to run the following commands to try to gather info, which I did: make -V DEFAULT_VERSIONS and ldd $(which curl). I also accidentally did a ld $(which curl); it gave me some sort of error which I don't recall (I think something something not found something something), I realized I had typed ld instead of ldd, and didn't think anything further about it.

I posted the results of those commands (besides the spurious ld), but mentioned that they were done directly at a shell prompt, so (as I use Synth) I wasn't sure they were giving the appropriate info. I then set about trying to get the same information from within the Synth building process; I knew this was possible and that I had done it before, but I didn't remember exactly how to do it. So I looked up an old thread on the Synth forums where the author had shown me how to do it (using the environment variable ENTERAFTER with synth test) and tried it out: env ENTERAFTER=configure synth test security/vault.

This is where I first noticed that something (other than my original security/vault problem) was not going as I expected: It did not break into the Synth environment. At first I thought it might be due to my choice of configure for the value of ENTERAFTER, so I started trying some of the other possible values (specifically, build, stage, and extract, but they all behaved the same way.

At that point I looked a little closer at the Synth output, and noticed something even more surprising: It was telling me that there was nothing that needed to be built. I say that this was "more surprising" because my Synth repository did not contain any package for security/vault, let alone the latest, and moreover (at least as I understand it) synth test should build the thing you ask it to build regardless.

I read that synth test could be also be used with a file listing things to be built rather than with a port, so I figured I'd give it a shot with a file listing the ports I normally tell Synth to build: env ENTERAFTER=extract synth test ./bobtmp. It first build ports-mgmt/pkg (which is unsurprising). But after that was finished (successfully), I was really surprised: It failed when trying to build every single other port.

After it finished up with all those failures, I tried running a full build as I normally do, without test or ENTERAFTER. It again tried building everything, which is yet another thing I was surprised by, as (prior to embarking upon all of this) the only thing Synth wanted to build was security/vault; everything else had been up to date.

That took hours, and was still chugging away when I went to sleep. It succeeded in building everything except security/vault. Sometime after that, my regular nightly script ran, updated the ports tree, and again was successful in building everything (well, everything which had been updated), and of course still failing security/vault.

And today, pkg upgrade gave me this "ABI changed" thing regarding a particular port.

 

[Charlie_]

misc/terminfo-db is just data, so it is architecture independent.
This is common to amd64, i386, etc.
The maintainer added this missing specification.
This is just a change to ports/pkg registration information and nothing actually changes.
This is probably unrelated to security/vault issues.
However, this was added in December of last year.

 

[rwv37]

Thanks Charlie_, that's a relief. Regarding the "added in December" thing, though: I've built everything essentially every day since them -- i.e. over a hundred times -- and upgraded it all dozens of times. Last 100% successfully around June 1 or something like that. So it seems strange that this would be reinstalled due to it now, no?