On Sat, Feb 16, 2013 at 8:14 PM, Allan McRae <[email protected]> wrote: > 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 > > > >
Does namcap currently warn about "official symlinks", such as /lib -> usr/lib? If not, it would be good to have namcap warn about these so problematic PKGBUILDs can be cleaned up sooner rather than later. This wouldn't help for custom symlinks, such as the /home/share kludge you mentioned, but I still see some value in it. Jason
