[pacman-dev] Remove directory symlink support in pacman-4.2 - Was: Use resolved paths for filelist operations

Allan McRae allan at archlinux.org
Sun Feb 17 22:47:54 EST 2013

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).


More information about the pacman-dev mailing list