Re: metadata layout problems and some history

On Fri, 2010-08-06 at 16:34 -0400, seth vidal wrote:

> So, with that in mind - I was hoping we could take this opportunity
> (since I saw a bunch of people just subscribed to the list) to discuss
> the problems we've had to work around and if we can make a new format
> that can:
> 
> 1. cover new changes to rpm packages
> 
> 2. make our workarounds less necessary/less painful
> 
> 3. work with new realities of interoperating with MANY MANY repos
> 
> 4. handle things that were never included in the original specification
> we've later found out would be useful.
> 
> 
> Think of this as compiling a list of issues to be solved with a Version2
> of things.
> 


Problems yum/fedora have had:
1. filelists are important to us b/c we have filedeps on pkgs - with
this in mind we need to further break out the filelists so a person who
is installing a pkg which requires a file outside of the ones included
in primary ends up downloading a big file from a lot of locations

2. translation information needed for summary and description.

3. potential for explosion in the provides/requires listing as per-pkg
find-prov/find-reqs become more common - essentially dealing with A LOT
more provides/reqs than we're used to - maybe as much as 1 or 2 orders
of magnitude.

4. allowing users to get partial updates to metadata easily

5. updating metadata in place w/pkgs removed/added (part of this is the
 fault of createrepo)

6. softdeps and where they should be stored.

7.  An occasionally-requested feature is to have the repodata also
contain (somewhere) the scriptlets (%pre, %post, %triggers, etc) of all
the pkgs - package collections as has recently been discussed on
rpm-maint will come into play there, too.

8. repository 'expiration'

9. fast random access to the metadata for searches from a variety of
tools - not just yum based ones.

10. repo labeling and repo 'dependencies' to 'help' in determining if
two repos have pkgs which can interoperate work with one another.


-sv