On 22/01/14 06:01, Nagy Gabor wrote:
Hello,
It seems I found a bug in pacman. Some information first: version: pacman 4.1.2-5 prebuilt from official repo system: Linux 3.12.7-2-ARCH i686
So it happened when I tried to remove alex package.
$ sudo pacman -R alex [sudo] password for michael: checking dependencies...
Packages (1): alex-3.1.3-1
Total Removed Size: 1.18 MiB
:: Do you want to remove these packages? [Y/n] y error: cannot remove file '/usr/': Read-only file system ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Read-only file system error: command failed to execute correctly
Uhm... I forgot I have root filesystem mounted read-only. No problem.
$ sudo mount / -o remount,rw $ sudo pacman -R alex error: target not found: alex
What? How could pacman remove the package from a read-only filesystem?
Well, pacman just removed the database entry (from the writeable /var/lib/pacman/)... This behaviour is clearly odd here, but it is not easy to say what is the expected behaviour in general, for example, what should we do when only ONE file cannot be removed? AFAIK, pacman cannot "undo" transaction after it has been started atm (transaction rollback is not implemented), so the only options are "pre-remove check" or stop.
Theoretically, pacman should collect "file foo has become untracked due to a removal error" somehow (for example, we could rename the package to alex-garbage in the database, keeping the non-removed files in its filelist), but that would definitely violate KISS and it would be not so easy to implement (directories are also listed in the filelist of a package, possible conflicts of garbage packages, etc.).
I cannot see a clean "filesystem check" solution neither.
I can... we already check if a filesystem is read-only during an install/upgrade (with the DiskSpace option). I think it would be quite simple to add a check before any package removal starts. I have opened a bug to track this: https://bugs.archlinux.org/task/38615 Allan