[pacman-dev] [PATCH] Readd some symlink checking in file conflict code

[Nagy Gabor]

> On Wed, Jul 23, 2008 at 8:14 AM, Xavier <shiningxc at gmail.com> wrote:
> > On Wed, Jul 23, 2008 at 2:53 PM, Dan McGee <dpmcgee at gmail.com>
> > wrote:
> >> I think we should just put some jury-rigged, hopefully passes both
> >> 003 and 004 code in here and really attempt to fix this on the
> >> larger scale post-3.2. Xavier, would a revert of my "useless
> >> check" patch solve the problem for now?
> >>
> >
> > Nagy clearly said that part is broken and does not even do what it
> > is supposed to do.
> > Besides, while 003 indeed passes, the similar 005 test case does
> > not. And finally, all the quick hacks I did like this during the 3.1
> > releases, "to be cleaned up for 3.2", are all still here.
> >
> > The only options I can support are the following ones :
> > 1) doing nothing. I was able to work around the xulrunner case just
> > fine with pacman -Rd xulrunner && pacman -S xulrunner
> > 2) nagy solution : check ownerships of all files inside the
> > conflicting dir 3) roll back system : FS#8585
> >
> > Note that all these options can be followed, in the same order
> > (first 1, then later 2, then even later 3).
> 
> OK, this is our blocker. I plan on pushing the rest of my stuff out
> tonight and that will be our 3.2.0 release if possible. What do we do
> here? I'd like a statement of exactly what to do (or nothing at all),
> or a patch to implement a short-term fix.
> 
> -Dan

IMHO nothing atm. Point 2) seems easy, but it is complicated: we must
ensure that just after remove_upgrade part of xulrunner, we have no
existing conflicting dir, checking ownerships inside the dir is not
enough, new appearing files (due to the upgrade of other packages) can
happen.

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*/
}