Yum, Proxy Cache Safety, Storage Backend

[James Antill]

On Thu, 2008-01-24 at 09:22 +0100, Nicolas Mailhot wrote: 
> Le Jeu 24 janvier 2008 04:04, Jesse Keating a écrit :
> > On Wed, 23 Jan 2008 21:41:40 -0500
> > Warren Togami <wtogami at redhat.com> wrote:
> 
> > In fact, I just tried this by hand.  I edited repomd.xml and changed
> > 'primary.sqlite.bz2' to 'primary-1234.sqlite.bz2' and then moved the
> > file on the file system.  Yum client didn't even blink, it happily
> > downloaded the -1234 file.
> >
> > So if this method is possible, does that change things for the better
> > for you?
> 
> I made the same analysis several months ago when I setup my own local
> mod_proxy cache. I'm glad to see Warren is getting through better than
> me at the time. Changing file contents while keeping the same filename
> is the ultimate proxy sin.

Wow, yeh that's one possibility, let's put that down here:

1. Warren managed to finally get through to the stupid yum developers by
having a flamewar on fedora-devel-list, they relented and have turned
the "do all the correct proxy stuff" option on for 3.2.9. Damn them,
infidels, if only they would have changed that option before!

Now we'll have a look around and come up with another possibility, just
as a control, and we'll put here:

2. Yum developers wanted to do transactions over the index and metadata,
to solve a whole bunch of problems and so said developers discussed the
details late-ish last year on #yum and yum-devel and even said it was
going to be fixed when Jesse opened a related bug[1] at the end of
November.  It was then written and tested by all of said developers,
over the next 6 weeks or so[2]. Then it was also discussed generating
unique names for the metdata itself within the index, now that we could
see both the old and new index and so do the right thing fairly easily.
Again, more testing and discussion and some code. Then the release of
3.2.9.


Now maybe it's just me, but I have an idea why #1 might not appear to
work so well over the long term ... but feel free to continue using that
method, if you think that's better.


[1] 405201

[2] upstream git commit c3d6b04587499992a32caf36ff3c6f03f8ef2426

-- 
James Antill <james at fedoraproject.com>