[Yum-devel] Package update metadata

[Luke Macken]

On Fri, Jan 13, 2006 at 01:39:01AM -0500, seth vidal wrote:
> I think just shoving them in 'repodata' would be messy. Maybe something
> off of there, though, so we can always find them.
> 
> However I think we should sort out the order of operations for getting
> this data in the right place.
> 
> What we had discussed before for this was:
> 
> 1. update info is out there in some db accessible via a cgi or generated
> into these files accessible somewhere.
> 2. user wants to make a repo out of some packages and wants to include
> this update information in his/her repodata.
> 3. user runs:
>  createrepo
> --update-info-location=http://url/to/cgi/or/something /path/to/pkgs
> 
> 4. createrepo grabs the update info .xml files from that cgi or path.
> 
> 
> Does that still make sense or is it just dumb, now?
> 
> I'm thinking about the people here who are respinning or being picky
> about the updates they get from their distro provider. People rebuilding
> the updates or splitting out some of them, for example, who cannot
> simply mirror.

I started writing some prototype code for the server (simple cgi script)
and client (createrepo) and ran into a few design questions that we need
to answer:

 o Flat file or database backend for the metadata server ?
   - if db driven, who should build the actual metadata structure, the
     server or the client ? (server takes data, makes metadata XML, sends
     to client -- or client recieves data, then creates XML).

 o 1 package == 1 query ?
   - I was thinking we could allow createrepo to just send the server a
     single query with every package in the repo and have the server just
     send a compressed XMLball back with all of the metadata.  Just an
     idea.

Thats all I can think off the top of my head this second, but I'm sure 
there are many more questions we need to ask.

What do you guys think ?


luke