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
On 21.01.2008 22:12, Michael Stahnke wrote:
This is an update on the ability for the EPEL project to provide accurate package metadata to our contributors and users.
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.
I didn't follow the whole metadata dicsussion to closely. But what you outline seems to me a bit complicated/overdesigned on the first sight; and using CentOS of course is fine, but is it still worth the work then?
I suppose CentOS provides some of the information you'd collect already, so why should EPEL provide them as well/replicate that informations? IOW: If we want to go the CentOS route then some docs that explain how to gather the needed data with repoquery from the CentOS repos might be the better way.
Than way the main thing left contributers might want to know are informations about the exact contents from the differnt RHEL variants, as for example the PPC variant of RHEL5 is only avilable as server and thus lacks a few desktop packages. That's afaics something EPEL contributers want to know.
CU knurd
epel-devel@lists.fedoraproject.org