[pacman-dev] lstat issue / fileconflict001 pactest + new failing pactest

[Nagy Gabor]

> 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.
OK. My main problems with rollback:
1. this doesn't look easy to implement at all
2. in case of powerbreak (or any small hidden bugs) I can get MBs of
"spam" on my HDD.
But I must admit, that I cannot work out any better solution :-(
> > PS: One more thing: What about fileconflict resolution? (using
> > query-fileowner)
> > 
> 
> What do you mean here?
This function can be disabled by default:
I mean, that targetlist<->hdd conflicts can be converted (in most
cases) to target_x<->local_package_y conflicts (query_owner); and then
these can be resolved like "dependency" conflicts.
You will say, that this will be extremely slow. I'm saying: not
necesserily:
1.
ngaba at durci:~# time pacman -Qo `ls -d /usr/bin/* | head
-n 1000` > /dev/null
real    0m43.998s
user    0m39.668s
sys     0m0.247s
2.
Obviously a radical speed-up can be done here: our
fileconflict_query_owner would check first the "already found"
conflicting localpkgs' filelists <- in real life examples this causes a
_big_ speedup.
3.
Usually targetpkg<->localpkg fileconflict is also a dependency
conflict (resolved _before_ fileconflict).
WOW, a bit off here: we just ran into an other reason for universal
transaction [or rollback?;-)]!!:
------
self.description = "fileconflict stops the remove-upgrade transaction after removal"

sp = pmpkg("pkg1")
sp.replaces = ["pkg3"]
sp.files = ["dir/file"]
self.addpkg2db("sync", sp)

lp1 = pmpkg("pkg3", "1.0-1")
self.addpkg2db("local", lp1)

lp2 = pmpkg("pkg2", "1.0-1")
lp2.files = ["dir/file"]
self.addpkg2db("local", lp2)

self.args = "-Su"

self.addrule("PACMAN_RETCODE=1")
self.addrule("!PKG_EXIST=pkg1")
self.addrule("PKG_EXIST=pkg2")
self.addrule("PKG_EXIST=pkg3")
self.addrule("PKG_VERSION=pkg2|1.0-1")
self.addrule("PKG_VERSION=pkg3|1.0-1")
----------
Bye, ngaba