Application for GSoC Project - Package WebUI

Toshio Kuratomi a.badger at gmail.com
Thu Mar 27 23:55:34 UTC 2008


Mark wrote:
> </snip>
>> 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 which is
>>  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 developer
>>  > 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 
wheel.

>  -Toshio
> 
> 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
> and PHP.
> 
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.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080327/be7b5593/attachment-0002.bin 


More information about the devel mailing list