[pacman-dev] refresh_pkgcache branch

[Nagy Gabor]

> On Fri, Jul 25, 2008 at 4:03 AM, Xavier <shiningxc at gmail.com> wrote:
> > On Fri, Jul 25, 2008 at 10:35 AM, Nagy Gabor
> > <ngaba at 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