[pacman-dev] Orphaning files in the filesystem after unsuccessful pacman -R

[smiszym]

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 <allan at archlinux.org>:
> 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
>
>