While playing around with some packages, I noticed that pacman has a small bug when two packages are installed that have a conflicting file.
I noticed this in two cases:
1. termcap.h in ncurses and termcap
2. readlink in coreutils and tetex
Once the two packages are installed (one being forced due to the file conflict), pacman can no longer distinguish which package actually own the file. It will also not detect file conflicts anymore. Also, when I updated tetex, it removed the readlink file that actually belonged to coreutils, so I had to install coreutils over again too to get readlink back. Here is a good example:
[root@limbo root]# pacman -Qo /usr/bin/readlink /usr/bin/readlink is owned by tetex 2.0.2-2 [root@limbo root]# rm /usr/bin/readlink -f [root@limbo root]# pacman -Sf coreutils :: coreutils-5.0-1: is up to date. Upgrade anyway? [Y/n] y Targets: coreutils-5.0-1 Proceed with upgrade? [Y/n] y loading package data... done. upgrading coreutils... done. [root@limbo root]# pacman -Qo /usr/bin/readlink /usr/bin/readlink is owned by tetex 2.0.2-2
I know the easy solution to this... don't force install any apps. Also, please don't interpret this post as complaining. It really doesn't bother me that pacman acts this way, as I can see what it is doing and anticipated the things that it did. I just thought the devs might find this info useful.
Don't forget to post your PKGBUILD in your thread when you announce a new package in incoming.
see HERE for details
i was aware of the coreutils/tetex readlink issue from the get go and this has been repaired.
to me it seems logical that pacman would be confused on ownership since forcing is basically telling pacman to do what it is told not to do. the best solution is to analyze the package and fix them accordingly so that they can coexist (ie removing of readlink from tetex appears to cause not issues).
I am not your friend
It would be neat if pacman kept some sort of counter and only removed the file when the last package using the file was removed. But then again like you say we could just try and avoid the conflicts. The only time that I have really had this as an issue anyway, is playing with building my own packages that are meant to replace another package I'm using and I haven't removed the soon-to-be-replaced package yet.