Metadata Assignment Update (and a query for help)

Michael Stahnke mastahnke at gmail.com
Mon Jan 21 21:12:49 UTC 2008


This is an update on the ability for the EPEL project to provide
accurate package metadata to our contributors and users.   The basic
idea is to have a place to look to find out names of packages, what
they provide, require, conflict with, etc, and maybe even have it
searchable.  This seems like an easy task at first.  When I started
looking into it, I thought I would do something with RHN+EPEL. However
certain restrictions with my account from $DAYJOB have prevented that.

Next, I thought I could just use the repodata off of Centos media.
Sure, it's not quite the same as RHEL, or the other EL's, but it's
probably what most contributors are using for testing (and mock uses
it also).  I worked with that for a while and wrote a nice little app
that spit out the package, provides, requires and such.  Then, I
wanted to add EPEL, and my repodata-fu was not good enough.
Additionally, I wasn't really sure I wanted to maintain another
metadata application (I'm more ruby than python, so that's why I
didn't start with repoview).  Also, the targets are moving.  So, if
today I have EL5.1 + EPEL, next month the repodata of both sides have
changed, and it needs to be kept  updated.  Then, the project will
require EL5.1 +EPEL-testing + EPEL-stable, for people looking to
contribute new packages and such. Basically, I am at a loss of how to
really tackle this again.  I thought I had a good handle on it, and
obviously don't.

My idea now is to mirror CentOS and EPEL and throw them into one
directory, run createrepo to get an SQLite DB made, then run repoview
and have that for EL5.1+EPEL+EPEL-testing. (Same thing for 4).  If
anybody has any better ideas, I would love to hear them.

stahnma




More information about the epel-devel-list mailing list