[pacman-dev] difficult symlink "puzzle"

[Xavier]

On Sun, Jul 08, 2007 at 10:30:58PM +0100, Andrew Fyfe wrote:
> Xavier wrote:
> > If we skip the second case, and the package has some files in file/dir, then
> > this is going to be weird :)
> We could move the file to *.pacold?
> 

Hm maybe, but why doesn't it just fail, as I said below?
Then the user can remove that file, or move it to whatever he wants, before
installing the package.

> > But what I don't get is why doesn't it totally fail in both cases ?
> > Shouldn't there be a conflict between a regular file and a directory ?
> > It looks like this isn't the case currently. Apparently, as long as there is
> > a directory on one side, conflict check are skipped. So there might be a
> > reason for that, I'm not sure..
> Yes if either side is a directory it's missed by the conflict checks. I 
> think the conflict checks need a similar solution to my patch for 
> add_commit().
> 
> > I think it's rather between a symlink to a directory and a directory that we
> > can choose between skipping and extracting, but I could be wrong.
> I don't understand (and a directory??), extracting a symlink over a 
> directory should NOT happen.
> 

I was talking about the case where we have "foo -> bar/" on one side,
and "foo/" on the other side.
We don't want to have a conflict in this case.
We have to choose between skipping and extracting, and we choose to skip (at
least when the symlink is on the filesystem side).
And I guess it could skip as well in the other direction (symlink in the
package, and real directory on the filesystem).
In that second case, it doesn't really matter though, because afaik libarchive
doesn't remove non-empty directories (while it does remove symlinks)
before extracting.

> 
> Slightly OT: Some work is still needed on permissions as well, I've just 
> noticed usr/man/man{1,4} are 0700 :@, not sure what package did it.
> 

Let us know if you find out how to reproduce it.