btw, this is my first ever bug report. please let me know if i've done anything wrong (too much/little information? wrong severity? etc...)


also, in retrospect, i think i that this latest update of pacman was the first since creating that community directory. so i have no idea if the bug is new to the latest version

I think pacman errors out because you put something over there that pacman couldn't overwrite. It's not version specific, it's a general problem with overwriting files.

oh, thats definitely WHY it errored out, but i think its a question of how it SHOULD error out.

creating the directory at first seemed like an innocuous thing to do, but it broke pacman, and i could only fix it by unpacking the pkg.tar.gz into /. I would think this is something newer users wouldnt want to face. especially since they can no longer use makepkg, pacman or abs to fix it since it is broken by this error.

also, i'm no code expert, but by looking at the error message, and the referred to code, it looked like the code could be fixed to respond more appropriately

let me try and say that again. two points:

1. the first error message, "could not extract etc/pacman.d/community: Is a directory", is all you need to see. the problem is that once you've gotten rid of the offending directory, you no longer have access to pacman. so if you try and move the directory and do pacman -S pacman, you get "bash: pacman: command not found"

2. isnt it normally a sign of a bug if running a program spits out raw error messages like "/var/lib/pacman/local/pacman-2.9.6-2/install: line 14: vercmp: command not found
/var/lib/pacman/local/pacman-2.9.6-2/install: line 15: [: -lt: unary operator expected"? someone on #archlinux suggested it reflected a bug in the code, which is why i filed the bug report.

What actually happens is that pacman tries to overwrite a directory with a file. Upon hitting this error, pacman bails out on the extraction procedure, which means half of pacman isn't installed. It then continues to the deletion of the previous version somehow and runs the postinstall script which uses commands not on your system anymore.

I think pacman should abort on these errors instead of just going on with tasks.

oh, thanks for explaining that. i was confused why the lines referred to in the error were part of the postinstall script.

yeah, pacman should DEFINITELY abort on the error, if not be able to go back to the original pacman it was updating.

if you're a newbie like me, trying to install pacman again without pacman or makepkg, is like trying to dload a network driver from the internet, because you need a netwrok driver from the internet to be able to connect to the internet

Aborting at the point of failure in this specific example would not have saved anything. It would have avoided the bash scriptlet errors at the end, but you would still be left without a pacman binary on your system.

The reason is that the old pacman was removed first. Then, during the install-the-new-pacman phase, the errors occurred and pacman bailed out.

The only nice way to fix something like this is with transactions, where one could roll back a failed upgrade. Pacman 3.0 has some transaction support, but I don't think it will be enabled by default (too slow for typical upgrades).

shouldnt a package manager check if an updated package is going to install without error (within reason), before deleting the previous one?

This has been fixed in CVS and will appear in the next pacman release.

Thanks.