[pacman-dev] [PATCH 4/8] conflict.c: use real path for filesystem checks

[Allan McRae]

On 29/04/13 00:59, Andrew Gregory wrote:
> On 04/29/13 at 12:33am, Allan McRae wrote:
>> On 27/04/13 10:00, Andrew Gregory wrote:
>>> In the event of a symlink<->dir transition, the paths for the incoming
>>> package need to be resolved to match the filelist for installed
>>> packages.
>>
>> Can you explain this to me?  Every time I think I understand, I don't...
>>
>> e.g.
>>
>> outdated local package:
>> /usr/foo -> /usr/bar/
>> /usr/bar/baz
>>
>> update sync package:
>> /usr/foo/baz
>>
>> So /usr/foo/baz is a new file so it is tested for presence in the
>> filesystem.  But /usr/foo/baz "exists" on the filesystem as /usr/bar/baz.
>>
>> From what I understand, you resolve the package file "/usr/foo/baz" to
>> "/usr/bar/baz" and note that it is in the old package so not a conflict.
>>  Which feels wrong to me...
> 
> Why would that be wrong?  /usr/foo itself isn't a conflict and both
> /usr/foo and /usr/bar/baz will both be removed/overwritten in the
> upgrade process so /usr/foo/baz should be fine, should it not?
> 
> In fact, we already do what you outlined (see the code below), this
> patch just does the resolution upfront so the real path can be used
> for the rest of the checks as well (ie "changing hands" from one
> package to another).

My point is, why do we need to do that at all?

Using my example again:

outdated local package:
/usr/foo -> /usr/bar/
/usr/bar/baz

update sync package:
/usr/foo/baz

Initially /usr/foo/baz is flagged as a potential conflict.  But because
the realpath of /usr/foo/ is not /usr/foo, we know there must be a
symlink to a directory somewhere in that path.  So, we know the symlink
is being replaced with a directory and either:

1) it can not be and has already been flagged as a conflict or
2) all files in this new directory are new and can not be conflicts.

Allan