On 18/02/13 14:30, Andrew Gregory wrote:
On Mon, 18 Feb 2013 13:47:54 +1000 Allan McRae <allan@archlinux.org> wrote:
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?
I was mostly just concerned about not removing functionality if we don't really need to. If there's really no need for it, I'm fine with dropping it.
Sure. And I know a lot of work has gone into getting this feature as fixed as it is now. But there were masses of issues discovered with this feature over the last year and there is a large increase in complexity in the conflict checking required to keep it. So I am not sure this feature is worth keeping - especially if no real use case can be made for it. Removing it simplifies conflict checking (see below) but also keeps the local pacman database correct as now people will not be able to replace a directory with a symlink. Anybody else want to give an opinion on this?
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).
Sorry, I meant that one of the packages has a directory that exists on the filesystem as a symlink, for example:
filesystem: /lib -> /usr/lib
pkg1: /lib/foo
pkg2: /usr/lib/foo
Without resolving /lib/foo we wouldn't be able to detect the conflict until we started committing the transaction and actually tried to extract the files.
If we removed the handling of symlinks for directories that would be detected as a conflict (/lib symlink on filesystem vs /lib directory in pkg1).