On Fri, Jul 25, 2008 at 4:03 AM, Xavier <shiningxc@gmail.com> wrote:

...

On Fri, Jul 25, 2008 at 10:35 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:

...

I just inform you that I warmed up my favourite bug-fix: http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/refresh_pkgcache

I had this for a while in my git repo, I thought it was ok, but I guess Dan did not find it important and was never in a hurry to merge it, so I eventually removed it. But he didn't say anything against it as far as I can remember, so you still have your chance :)

Looking at this now I have some concerns that may be unfounded, but enough that I don't want to put this in 3.2.0. For instance, what if the lastupdate time fails to be set (as could be the case with an older FTP server or something)?

-Dan

OK. I also think that merge to 3.2 would be too fast. With the current front-end we have _zero_ slow-down in refresh_pkgcache call, because our pkgcaches are not loaded when pacman front-end calls trans_init(). (Even getlastupdate() won't be called...) (After the patch you get an extra setlastupdate in trans_release()). So your question is theoretical with pacman front-end. lastupdate time is something like "revision", if it is set/got incorrectly, for example two different db state get the same revision-number (probably 0), we get the current situation: A sync pkgcache may become outdated, which is not a big problem (outdated _local_ pkgcache is the real problem, where setlastupdate should work perfectly -- however, setlastupdate may need fine-tuning). I have a little problem with local setlastupdate in trans_release: Probably I will move it to trans_commit, since we use transactions for simple db lock, too. But trans_commit can be called with -Sp, and -Sw; where setlastupdate is needless again. But imho these are little issues, I put its "principle" here to discuss. Bye