Dan McGee wrote: > On Wed, Jul 23, 2008 at 8:14 AM, Xavier <[EMAIL PROTECTED]> wrote: > >> On Wed, Jul 23, 2008 at 2:53 PM, Dan McGee <[EMAIL PROTECTED]> 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. >
I'm happy doing nothing but a short-term fix to get this back to at least not being a regression on 3.1 would be best. If it can pass more of the fileconflict pactests, then good but from what I understand about this bug, a complete fix is too big of a change at this time. Allan _______________________________________________ pacman-dev mailing list [email protected] http://archlinux.org/mailman/listinfo/pacman-dev
