FS#8156 - pacman does not detect conflict between symlink and files/directories
Attached to Project:
Pacman
Opened by Pierre Schmitz (Pierre) - Friday, 28 September 2007, 18:25 GMT
Last edited by Dan McGee (toofishes) - Sunday, 06 January 2008, 17:34 GMT
Opened by Pierre Schmitz (Pierre) - Friday, 28 September 2007, 18:25 GMT
Last edited by Dan McGee (toofishes) - Sunday, 06 January 2008, 17:34 GMT
|
Details
Summary and Info:
If there is a directory which belongs to an allready installed package and the user installs a new package including a symlink named after that directory, pacman does not detect this conflict and just ignores the symlink. This should not happen; especially when the directory and the target of the symlink are different. Steps to Reproduce: This problem is the reason of this Bug: http://bugs.archlinux.org/task/8141 Here are two PKGBUILD to reproduce the problem. Pacman does not complain about anything when installing test1 after test2. But the symlink in test2 is lost and software which relies on this will stop working. [code] pkgname=test1 pkgver=1 pkgrel=1 arch=('i686' 'x86_64') build() { install -d $startdir/pkg/test/ touch $startdir/pkg/test/file } [/code] [code] pkgname=test2 pkgver=1 pkgrel=1 arch=('i686' 'x86_64') build() { install -d $startdir/pkg/test2/ touch $startdir/pkg/test2/file2 ln -s $startdir/pkg/test2 $startdir/pkg/test } [/code] |
This task depends upon
Closed by Dan McGee (toofishes)
Sunday, 06 January 2008, 17:34 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in GIT.
Sunday, 06 January 2008, 17:34 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in GIT.
bug 7484?I can't reproduce this with either 3.0.6 or 3.1. Maybe I'm doing something wrong..
But while it works with 3.1, I didn't get the expected behavior.
I thought it was supposed to trigger case 9 : /* case 9: existing symlink, dir in package */
But the --debug output shows this message : extract: skipping dir extraction of %s\n
which is the case 12. So I'm pretty confused..
bug 8141, which helped me understand the problem.You needed a /usr/lib/php/extensions -> /usr/lib/php/20060613/ symlink.
The problem is that there already was a /usr/lib/php/extensions/ directory on the filesystem, so you couldn't replace it by a symlink, right?
I think you made a typo that confused me : "Pacman does not complain about anything when installing test1 after test2"
Didn't you mean installing test2 after test1? Because that would try to replace the test/ directory by a test symlink.
Maybe it would be better if pacman just failed in this case indeed, instead of just ignoring it.
So in pacman code, that's case 11: existing dir, symlink in package, ignore it.
However, we can't easily fail here, because it happens during the extraction. We are back to the problem in
bug 7652,where we would need a rollback system to handle this properly.
FS#8141closed, is this closable?libalpm/conflict.c :
396 if(S_ISDIR(lsbuf.st_mode)) {
397 _alpm_log(PM_LOG_DEBUG, "%s is a directory, not a conflict\n", path);
If a directory exists on the filesystem, it never treats it as a conflict, even if the package contains a file or a symlink of the same name.
It would probably be better to fail in this case, as mentioned in the title of this report.
http://www.archlinux.org/pipermail/arch-dev-public/2007-December/003869.html
I just tried to hack something together.
I also had to fix a little problem in pactest that I noticed a while ago, and finally figured out.
As Nagy said, 001 might be fixed using realpath. I just gave it a try but failed. And 002 looks pretty hard to fix.
In any cases, these are different problems. So if you pull my patches, I think this bug can be closed.