[pacman-dev] Orphaning files in the filesystem after unsuccessful pacman -R
smiszym at gmail.com
Wed Jan 22 10:33:03 EST 2014
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.
2014/1/22 Allan McRae <allan at archlinux.org>:
> On 22/01/14 06:01, Nagy Gabor wrote:
>>> 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:
More information about the pacman-dev