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
