On 16/02/13 12:02, Andrew Gregory wrote:
Properly handling symlinks requires using resolved paths. I'm not sure if returning strings instead of file_t structs is the best solution, but it seemed like the least drastic one as we prepare for 4.1 and we weren't using the extra information anyway.
Thanks for catching this and the patches - I made one small comment. This whole situation is beginning to really annoy me... I know we (especially you) have put a lot of work to get symlinks to directories working so that when /lib -> usr/lib we now can deal with /lib/foo and /usr/lib/foo conflicting etc, but having to stat every directory to determine if it is a symlink and the resolve it is just wrong. So here is what I am proposing. Get pacman-4.1 out the door with these patches included. Then the sole focus of pacman-4.2 should be stripping support of symlinks to directories out of pacman. If /lib is a symlink on your system, no packages should put files in /lib. Just make that a conflict. If a package MUST put files there, the package() function in the PKGBUILD should look like: package() { ln -s usr/lib ${pkgdir}/lib make install rm ${pkgdir}/lib } Done... The only other reason these are used (that I have seen...), is poor man's mount points. For example, your /usr partition is getting full and you decide to put it on your /home partition in /home/share (yes - I have seen that done...). The are more correct options that should be used here - preferably resize your partitions or create a new partition. On Linux, a bind mount could be used. Overall, I see no need to keep this mis-feature. So, I am proposing, get this patchset merged and get pacman-4.1 out the door. The just concentrate removing all directory symlink support from pacman. The only thing that would need to be done here is to check all current packages do not have paths in them that require resolving symlinks to directories. E.g. on machines with /lib -> usr/lib, no package should have a file in /lib. I propose that in a 4.1.x point release, we should add a tool (or perhaps extend testdb) to detect these packages and print a warning. So a bit of planning is needed, but I think it can be done. Comments? Allan