On 18/02/13 12:52, Andrew Gregory wrote: > Having reviewed the related code far more than I never wanted to, I > believe I can get the number of resolved paths down to a manageable > level while keeping full symlink support. We should be able to take > advantage of the fact that symlinks in paths are not the norm and file > basename collisions are actually quite rare to selectively resolve > individual paths as necessary instead of resolving whole filelists. I > haven't worked out all of the specifics for doing this efficiently, > though, so it may not be worth it in the end.
It would be great if the amount of resolving could be reduced greatly. But what is a real use case for this feature? > If we do remove support, we should probably at least still use resolved > paths to check for inter-target conflicts. If one target has a symlink > in its paths I don't see any other way to catch a conflict prior to > actually extracting the files. As long as we only resolve files that > are new in the package and packages don't constantly move files around, > this should have only a small performance hit most of the time. I don't understand this. A package can not have a symlink to a directory and files in the directory too. E.g. a package can not have /lib -> usr/lib and /lib/foo. So there is no need to resolve there. Or, a symlink one package and a directory is in the other would generate a conflict (as happens currently). What would change is that we currently allow these to be installed in separate transactions (symlink containing package first). Allan
