Idézet Xavier <shinin...@gmail.com>:
On Fri, Jul 25, 2008 at 2:11 PM, Nagy Gabor<ng...@bibl.u-szeged.hu> wrote:
> If you want to restore our old negligent "eye-candy" behaviour, you
> can do the following (pseudo-code):
> if(isdir(local_conflicting_stuff) &&
> alpm_list_find_str(oldpkg->files,local_conflicting_stuff) {
> continue; /*no conflict*/
> }
>
I would say go ahead with the current code for the 3.2 release. If it
turns out to be really problematic, we can always use the above code
for 3.2.1.
(again, it is a matter of choosing which case is more important
between fileconflict003 and fileconflict004)
I might have not clear, I also vote for this (I just said above, that
forget that ugly i-node hack part.) I tell you why:
The current 3.2 code is _safer_. With the old one, we had a failing
fileconflict005.py pactest (maybe we should put it to git), which is
problematic, because your installed package will be broken.
Currently the code is "too safe", this is the problem, but this causes
just "annoyance" and can be fixed with -Sf.
I am not sure what to do.
It seems the situation of fileconflict004 happens regularly, see for
example :
http://www.archlinux.org/news/444/
And I believe there were also other cases since 3.2 was released.
So maybe we should implement the pseudo-code that Nagy proposed above.
I have a simple patch locally which works.
Well, I would be happy with a bit more careful code. I think we need a
"fast" check (no realpath etc.) to ensure that all files in the dir
will be removed in oldpkg removal. If all files of the conflicting dir
will be removed by oldpkg, then go ahead. (Don't check other packages,
only the old version of the package in question, this is important to
eliminate the "file relocation" hack.) Even this doesn't ensure that
the directory will be removed (.pacsave, NoUpgrade etc), but this is
more than nothing. Unfortunately here we need a recursive stuff...
Then fileconflict005 fails, but this is probably a less common
situation. And pacman will just fail to detect the file conflict, and
skip the extraction of a file or a symlink (because a non-empty
directory exists).
Though, I don't understand why pacman shows an error in case of a
file, and nothing (only a debug message) in case of a symlink (case of
fileconflict005). So I would suggest displaying an error in case of a
symlink as well, to have an output as follows:
------------------------------------------------------
SZTE Egyetemi Konyvtar - http://www.bibl.u-szeged.hu
This message was sent using IMP: http://horde.org/imp/
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://www.archlinux.org/mailman/listinfo/pacman-dev
