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).
- /* check if a component of the filepath was a link. canonicalize the path - * and look for it in the old package. note that the actual file under - * consideration cannot itself be a link, as it might be unowned- path - * components can be safely checked as all directories are "unowned". */ - if(!resolved_conflict && dbpkg && !S_ISLNK(lsbuf.st_mode)) { - char rpath[PATH_MAX]; - if(realpath(path, rpath)) { - const char *relative_rpath = rpath + rootlen; - if(alpm_filelist_contains(alpm_pkg_get_files(dbpkg), relative_rpath)) { - _alpm_log(handle, ALPM_LOG_DEBUG, - "package contained the resolved realpath\n"); - resolved_conflict = 1; - } - } - } -