[Rpm-metadata] discussion of createrepo and repodata format future

[seth vidal]

On Fri, 2010-08-06 at 14:55 +0200, Klaus Kaempf wrote:
> * seth vidal <skvidal at fedoraproject.org> [Aug 06. 2010 14:34]:
> > 
> > When you think about it - the xml format is a cache, too. It's a
> > compilation, truncation and compression of the data in the rpm hdrs.
> > 
> 
> Actually, it serves two purposes (requirements)
> 
> 1. caching of rpm header information
> 2. providing a universally understood format ("XML's design goals
>    emphasize simplicity, generality, and usability over the Internet"
>    (according to http://en.wikipedia.org/wiki/XML)
>    
> I'd like to add a third requirement
> 
> 3. minimize download time required by clients to update their knowledge
>    about a repository
>    
> Having read through the archive of this discussion, the thread started
> with a proposal to improve #3, namely adding a better compression
> scheme.
> 
> 
> Are there other or different requirements for a repository metadata
> scheme ?

I think a few more things are 'important to have' but not necesarily
'requirements':

1. make it relatively easy to provide translations of key pieces of
metadata - in this case summary and description

2. make it possible for the list of files in all pkgs to explode
exponentially w/o crippling the ability to depsolve pkgs

3. deal more gracefully with... umm.... poor packaging choices and
deps/provides generators that are a bit too excitable - we had an issue
in fedora with the erlang pkgs where the deps/provides went from about
30-40 per pkg to 20000 per pkg. That, obviously, made the metadata
balloon in size. We were able to shut down that particular nightmare but
it won't be the last one. Kernel interfaces are going to do this
eventually.

4. retain the ability to gpg/x509/etc sign the top layer (repomd.xml)
and use hashing to verify everything else the rest of the way down.


#4 there is moot - but it is important for security reasons.

-sv