interrupting xbps-install in the middle of configure step leads to confusing behavior

[lun-4]

Here's what I did:

• xbps-install -Suv after some weeks
• I got some hundred packages to update
• CTRL-C'd in the middle of a package configuration (in this case, nvidia)
• ran xbps-install -Suv after that, hoping that it would continue where it left off with nvidia

Instead, I rececived this transaction:

Name         Action    Version           New version            Download size
libgcc       configure 12.2.0_2          12.2.0_2               -
liblzma      configure 5.4.1_1           5.4.1_1                -
libstdc++    configure 12.2.0_2          12.2.0_2               -
libcrypto1.1 configure 1.1.1t_1          1.1.1t_1               -
libssl1.1    configure 1.1.1t_1          1.1.1t_1               -
python3      configure 3.11.2_1          3.11.2_1               -
gdb          update    12.1_3            13.1_1                 4069KB
gdb-common   update    12.1_3            13.1_1                 824KB

Size to download:             4893KB
Size required on disk:          12MB
Space available on disk:        82GB

nvidia is not included. I assume gdb is being updated as the repository just got the new package version, leading to configure steps being created for other packages.

I had to do xbps-install -f nvidia so that the package is built for all my kernel versions. And now I'm running xbps-reconfigure -a to be sure that all packages are in the proper state in my system. Example, with zola, which doesn't provide any configuration steps:

short_desc: Fast opinionated static site generator
source-revisions: zola:5d787e2874
state: unpacked

Then its state after xbps-reconfigure -a:

short_desc: Fast opinionated static site generator
source-revisions: zola:5d787e2874
state: installed

Maybe xbps-install -Su should do the configure steps if a package's state is set to unpacked but not installed, so that a user wouldn't have to run xbps-reconfigure -a on top?

[Anachron]

Maybe we need a new command (flag) and xbps could check first whether we have an inconsistent state from an aborted upgrade?