* Two fixes when running under a new root (-r|--root)

    - Check EACCES in can_remove_file, to verify - we're only checking for a
      read-only FS here... if write permissions fail, we can still remove it
    - Switched the message when creating DB directories from an error to a debug
      message
* Fix the dep tests once and for all (it wasn't working for provides=()
  packages)

1 files changed, 3 insertions, 3 deletions

diff --git a/lib/libalpm/remove.c b/lib/libalpm/remove.c
index fed86b0c..47e5cfe7 100644
--- a/lib/libalpm/remove.c
+++ b/lib/libalpm/remove.c
@@ -169,9 +169,9 @@ static int can_remove_file(pmtrans_t *trans, const char *path)
 	/* If we fail write permissions due to a read-only filesystem, abort.
 	 * Assume all other possible failures are covered somewhere else */
 	if(access(file, W_OK) == -1) {
-		if(access(file, F_OK) == 0) {
-			/* only return failure if the file ACTUALLY exists and we don't have
-			 * permissions */
+		if(errno != EACCES && access(file, F_OK) == 0) {
+			/* only return failure if the file ACTUALLY exists and we can't write to
+			 * it - ignore "chmod -w" simple permission failures */
 			_alpm_log(PM_LOG_ERROR, _("cannot remove file '%s': %s"),
 			          file, strerror(errno));
 			return(0);