[arch-general] pacman bug? (can't replace dir with file)

[RedShift]

Aaron Griffin wrote:
> On Mon, Mar 23, 2009 at 1:30 PM, Jan de Groot <jan at jgc.homeip.net> wrote:
>> On Mon, 2009-03-23 at 19:08 +0100, Damjan Georgievski wrote:
>>> error: failed to prepare transaction (conflicting files)
>>> test: /test exists in filesystem
>> I think it has to do something with this:
>> [jan at server ~]$ pacman -Qo /usr/share/vte
>> error: cannot determine ownership of a directory
>>
>> The point with directories is that there's no real ownership, as lots of
>> packages can store files in such a location. Now, what would have
>> happened if your directory on the filesystem contained files not
>> belonging to the package that is upgraded?
> 
> True, but pacman should probably check to see if the dir is empty, and
> replace it if it is.

That seems like something dangerous to do, what if package A installed for example, /var/lock/mysoftware/ to keep locks for multiple purposes, and you install package B, which replaces /var/lock/mysoftware/ with a file called /var/lock/mysoftware (because /var/lock/mysofware/ happens to be empty at that point), causing package A to break.

Not only does it give the potential to break software (bad) instead of erroring out (good), it gives inconsistent results across multiple systems.


I wonder what would happen in the case of:
> 
> packageA: /foo/bar normal file
> packageB: /foo/bar/baz normal file
> 
> With packageA installed, attempting to install packageB. I'd hope it
> would error out somehow
> 
>