> The other option is to get this information from the yum repodata. This
> lacks historical information (it's only information in the present
> repository) but that may be the way to go for several reasons:
> * We've had issues with kojidb failing to scale under the load that koji
> can place on it (we'll be getting a database server dedicated to koji at
> some point which may alleviate this but that's both speculative and
> something for the future.)
Than i suggest we wait till this is resolved. Using the repodate,
parsing that and kepping that up to date is way harder than using
koji's db. Another option might be to have a seperate database with
only the needed information that is synced with koji everyday.
No parsing necessary. repodata is available as an sqlite database. yum
has API to find, and download the repodata already. Copying and syncing
the data around strikes me as extra work.
> * repodata will show what's available to yum for downloading
> synced with what an end-user will see.
Like said.. doing it this way will make it extra hard while it's not
needed (or should not be needed).
That really depends on what you are expecting the end application to
look like. Who you're serving and what they need to see first.
> > And last question. How do you need to make it? Make it with
> > visitors in mind (so making it a bit technical won't do much harm) or
> > make it so that Everyone can use it, even the completely new linux
> > user which only knows a few basic computer things?
> The initial proposal sounds like the latter.
> > Also if making it for the last group (which i expect) than it might be
> > handy to make something of a firefox plugin (or something else) as
> > well to just click "install" in the WebUI and than the package gets:
> > Downloaded and Installed. And then i don't mean the normal FF download
> > window and then double clicking on the rpm file.
> That could be handy but it would need to be talked over with the
> PackageKit authors rather than me :-)
What does PackageKit have to do with it?
Isn't it just a "yum -y install %package_name%" command that needs to
be executed.. i don't see how PackageKit fits in this.
1) If you're on Fedora 8 and you click on the rawhide version of a
package you're going to need more than that to install it.
2) PackageKit is working on a way to do this already so why reinvent the
About the language it needs to be written in.. (Python).. byw bye
oppertunity for me to make it unless i learn python :) i do know Java
That's too bad. Unfortunately, especially with something like GSoC it's
imperative to have something at the end that we can maintain. Having an
add on written in java or php, especially when its going to be working
with a project already written in python is just going to be trouble.