Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#43286 - [paccache] -u option targets all packages if libalpm error

Attached to Project: Pacman
Opened by Dario Giovannetti (kynikos) - Thursday, 01 January 2015, 04:04 GMT
Last edited by Allan McRae (Allan) - Monday, 12 January 2015, 05:30 GMT
Task Type Bug Report
Category Scripts & Tools
Status Closed
Assigned To Dave Reisner (falconindy)
Architecture All
Severity Low
Priority Normal
Reported Version 4.2.0
Due in Version 4.2.1
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

Running `paccache -?u` targets all the packages in the cache if there's a libalpm error.
In particular, this completely clears the cache if used as `paccache -ruk0`.

This happened to me because I'm used to running a `paccache -rvv && paccache -rvvuk0` alias after every system upgrade (k=3 by default): with the update to pacman 4.2 (from 4.1) the database should have been upgraded manually, but no news entry was posted in archlinux.org, nor a post-upgrade message was printed by pacman, so I just ran the alias and my cache was cleared.

Steps to reproduce:

1) Boot an Arch Linux live installation image with pacman<4.2
2) Run `pacman -Syy pacman`
(This puts curl and pacman in the cache)
3) Run `paccache -ruk0`

This will output:

error: failed to initialize alpm library
(database is incorrect version: /var/lib/pacman/)
error: try running pacman-db-upgrade

==> finised: 2 packages removed (disk space saved: 1.37 MiB)

No package should have been removed, since curl and pacman are still installed.
Note that the error message does suggest to run `pacman-db-upgrade`, but in this case it's too late :)

Maybe a solution could be stopping `paccache -?u` from working if there's an error.
This task depends upon

Closed by  Allan McRae (Allan)
Monday, 12 January 2015, 05:30 GMT
Reason for closing:  Fixed
Additional comments about closing:  git commit e8d757b6ba
Comment by Pablo Lezaeta (Jristz) - Thursday, 01 January 2015, 08:18 GMT
also paccache think that an incompatible database is an empty one and proced to perform operations, instead of exit or even warning.
Aso I'm inclined to thing that paccache never exit on erorr like this, siomply prossed.
Comment by Dario Giovannetti (kynikos) - Friday, 02 January 2015, 14:06 GMT
This patch fixes the bug for me.
   FS#43286.patch (0.9 KiB)
Comment by Dave Reisner (falconindy) - Friday, 02 January 2015, 15:36 GMT
I don't think it's enough to just exit when pacman -Qq exit non-zero. We should call die to explain why *paccache* is exiting with an error rather than assuming that the last error seen explains it (it won't).
Comment by Dario Giovannetti (kynikos) - Friday, 02 January 2015, 15:52 GMT
True, I guess you want to keep it short, how about "could not retrieve the list of installed packages"? The other die messages aren't adding line breaks; do you want to add a gap here between pacman's message and paccache's?
   FS#43286.patch (0.9 KiB)
Comment by Dave Reisner (falconindy) - Friday, 02 January 2015, 15:59 GMT
I think it's sufficient to just use:

(( ${#ign[@]} )) || die 'failed to retrieve the list of installed packages'

No need for any extra line breaks.
Comment by Dario Giovannetti (kynikos) - Friday, 02 January 2015, 16:13 GMT
Yep, all done.
   FS#43286.patch (0.9 KiB)

Loading...