Well, I am unable to understand that code, but maybe Nagy did, since he was able to provide a (fileconflict005 ?) pactest which fails after this patch : http://archlinux.org/pipermail/pacman-dev/2008-July/012522.html That pactest also triggers this "%s is a symlink to a dir in previous package\n" message which looks totally bogus.
OK. That ugly (not portable?) inode hack catches this case _accidentally_ which can be replaced by a much "cheaper" test, if needed. So what is happening here? See commit 584ffa6aef13d0933ad4930ab9cb70d3af2977ff. First of all, that part checks whether the _local file_ is a symlink pointing to a to-be-removed file (dir?). I don't see why this case should be handled at all. Clearly, this is not that case, we have a local conflicting _directory_, not symlink, but the code believes that it is that case. To be short: S_ISLNK(lsbuf.st_mode) check is missing from the removed code-part. This leads to the false decision which is good from fileconflict004.py viewpoint. See the decision part: if(!_alpm_lstat(str, &pkgbuf) && lsbuf.st_ino == pkgbuf.st_ino)... /* lsbuf represents the conflicting file, pkgbuf loops over the 'files' of local package */ Since there is no symlink here, _alpm_lstat is equivalent with stat (the code _assumed_ symlink here). So this part will simply detect that our conflicting directory belongs to the local package 'files' list. (Which doesn't mean that it will be removed, see fileconflict005.py). So if you want to restore the old behaviour, this code-part can be replaced with an easy "find directory-name in localpkg's filelist" search (maybe tuned with realpath).
"/path/to/pacman/root/test is a symlink to a dir in previous package"
I don't see how this reflects the situation of "fileconflict005" at all. In the new package, test is a symlink to a new directory test2. and test2 did not exist in any previous package. However, test existed in previous packages, as a directory.
Anyway, here are the different ways I propose to deal with this issue : 1) choose that fileconflict003 is more important than 004, and only supports that situation (current 3.2 code) 2) choose that 004 is more important than 003, so slightly edit the code to get back to this old behavior (of 3.0?) 3) we decide that we need to support both, in that case we go the way that Nagy suggested in the beginning : http://archlinux.org/pipermail/pacman-dev/2008-July/012470.html
I am considering a "cheaper" solution now, only check the old version of package (not the whole target list). But that cannot My opinion about fileconflict check, that it is really fast, but it has some bugs (most important: trans001.py). I think we should decide if we want to implement FS#8585 *soon* or not, that would solve most of these issues. If we want, I don't think we should waste too much effort to this to-be-removed fileconflict check part. Bye