In fact, the first thing I thought about when noticed a bug was that pacman actually checks before installing - but I forgot to mention it.
Of course, there are probably lots of things not worth implementing because pacman is by its goal simple (and I like it especially for its simplicity). However, checking for a filesystem being read-only is rather basic feature in a package manager. Thanks for your fast response and for opening a bug in tracker. Pozdrawiam, Michał Szymański 2014/1/22 Allan McRae <[email protected]>: > 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 > >
