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