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

[Allan McRae]

On 18/02/13 14:30, Andrew Gregory wrote:
> On Mon, 18 Feb 2013 13:47:54 +1000
> Allan McRae <allan at 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).