interrupting xbps-install in the middle of configure step leads to confusing behavior
lun-4 opened this issue · comments
Here's what I did:
xbps-install -Suvafter 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 -Suvafter that, hoping that it would continue where it left off withnvidia
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?
Maybe we need a new command (flag) and xbps could check first whether we have an inconsistent state from an aborted upgrade?