[pacman-dev] lstat issue / fileconflict001 pactest

[Xavier]

On Sat, Nov 10, 2007 at 07:14:11PM +0100, Nagy Gabor wrote:
> Hi!
> 
> To be honest, I don't like the rollback solution; the pre-transaction
> checking is much more elegant (for me).
> As I mentioned earlier my preferred fix to fileconflict001.py is:
> converting the filelists with the help of realpath(); so we get the
> "after-install" state of our filesystem.
> Note: realpath() is quite an "intelligent" function:
> realpath("/usr/var/blabla", ...) will result /var/blabla [blabla
> doesn't exist of course].
> Some contras:
> 1. speed?! (needs testing; but during targets<->HDD check, all entries
> of filelist is alpm_lstat-ed, so this hopefully won't cause terrible
> slowdown neither, but I dunno.)
> 2. fileconflict002.py ?! (a possible solution: create temporarily
> the newly installed symlinks <- can we get this info from libarchive?
> then using realpath -- I'm suggesting a "1. create new symlinks
> first" (if possible), _then_ "2. extract tar.gz-s" ugly hack here)
> 

I think your are contradicting yourself in this mail :)
Sure, pre-transaction checking seems more elegant at first sight, but it's
not practical. Either you try to keep it simple, but then it's not safe or
correct. Or you try to check all possible cases, and then it's a nightmare.
You said yourself solving fileconflict002 would require an ugly hack. It
would be half pre-transaction checking / half rollback way. So it would be
probably better to do fully the rollback way.

Besides, you are only considering the case of file conflicts here. For
removing files, it's the same mess. See bug 7652.
You can also look at bugs 3564, 7692 and 8585.

However, it's hard to tell how difficult it would be to go the rollback way
before actually doing it. Probably a poor implementation of it would result
in a worse situation than the current one.
There are many corner cases where pacman currently breaks, but it still does
a good job most of the times, so that might be good enough.

> PS: One more thing: What about fileconflict resolution? (using
> query-fileowner)
> 

What do you mean here?