On Wed, Jul 23, 2008 at 8:14 AM, Xavier <shiningxc@gmail.com> wrote:
On Wed, Jul 23, 2008 at 2:53 PM, Dan McGee <dpmcgee@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*/ }