a better webinterface to our packages (Was: Re: New Fedora Extras Steering Committee chair)

[Konstantin Ryabitsev]

À 15/01/06 04:47 PM, Andreas Bierfert a écrit:
> Repoview on the mirrors is great. I is easy to use, static and good enough to
> find your way around on a mirror. What I would like to see for FC + FE (and
> livna ;) ) is a webportal which offers searches and a nice view on things.

The Repository-That-Must-Not-Be-Named won't be allowed on an 
official resource run by the project in any shape or form.

> Form the tech side I would like it to be part dynamic part static, not use yum
> in any way (just the repodata files) and besides LAMP not require anything on
> the server side.

1. You realize that "besides LAMP not require anything on the server 
side" will pull in a whole lot more requirements than "have anything 
other than LAMP"? :)
2. "Not use yum in any way" is going to quickly become 
counter-productive, since you will have to replicate all of the 
functionality already included in yum, and do it in PHP of all 
things. Your codebase will balloon for no apparent purpose other 
than "not depending on yum."

> The way I would like it to work is something like this: Have a dbms with a
> special layed out database which gets updated with package information on each
> push. The webportal will then work with this database to create its dynamic
> pages on request.

The dbms already exists – yum caches all package data in sqlite 
databases. You'll be duplicating a lot of effort. Much easier to 
just reuse what yum already does well and fast.

> As opposed to repoview (am I correct here?) I want it to maybe view a nice shiny
> table for the supported arches also have the requires, description, summary, evr
> and so on, have a download link, information on how to install this special
> package (with yum), links to bugzilla to file bug reports and all the nice and
> nifty features one can think of.

The only things you list that repoview doesn't already do is:

1. Doesn't provide information on how to install this package with 
yum, since repoview is repository-agnostsic. Moreover, this isn't 
dynamic information, so can be easily added by just editing the 
template files. This will probably be incorporated in a future 
version of repoview – I plan to change the API so you can just pass 
a yum.conf file to it and let it do the rest automatically.

2. Doesn't list the requires, since the output in its default format 
  is really verbose and not useful:
icon at protee:[~]$ rpm -q --requires abiword | wc -l
89
This includes things like libstdc++.so.6(GLIBCXX_3.4.6) and 
rpmlib(VersionedDependencies) <= 3.0.3-1. This is eye-glazing 
material. Moreover, this doesn't handle nested requirements, so 
listing "foo requires libfoo" won't be very useful if libfoo 
depended on something like kde-libs.

To be useful, every "requires" line needs to be resolved by yum to 
specific packages, with links provided, preferably excluding the 
"core system" since you don't want to list libc and bash on every 
page. However, this is a REALLY expensive operation, and if repoview 
did something like this, the generation time would go from 80 
seconds to something like 80 minutes for 3000 packages.

I've considered requirement information extensively and didn't find 
an easy and useful way to list this data, which is why it's not 
listed at the moment. Would it be useful? Maybe. Currently the 
drawbacks significantly outweigh the benefits.

3. Link to a bugzilla is also non-dynamic information and I doubt 
how useful it would be, since anyone who knows that "bugzilla" is 
not some bad B movie from 70s is not likely to use package search to 
file a bug. A better solution is "Click here if you need support for 
this package" that would link to a wiki/doc page listing the support 
options.

Everything else repoview already does. It already lists all 
available architectures for a package, e.g. see:

http://linux.dell.com/yum/software/rhel4/repodata/repoview/unshield-devel-0-0.5-2rhel4.html

> An the user side everything should be easy to use, have a nice layout (css
> based) and maybe even support some level of wcag while at it.

Repoview already uses CSS, and I dare you to find where it's not 
WCAG compliant. :)

> For developers maybe some information on how to checkout this module from cvs
> and so on...

This is, again, not dynamic content, and the usefulness of such link 
isn't directly useful. The URL field already provides the 
information on where to find more information about this software, 
and fedora CVS isn't externally accessible for non-developers 
anyway, while developers already know how to check out that module 
from CVS.

> I will get working asap. As this is a community project comments and suggestions
> will of course be discarded :P

I have a counter-offer. I will write a small addition to repoview 
that would offer a small outward-visible python script, requiring 
just a cgi-bin directory. This script will accept one parameter – 
query term that would be matched against name, summary, and 
description of each package and output the links to static repoview 
pages of all matched packages.

I estimate that this will fit in 200 lines of code, potentially 
less. I also estimate that this will satisfy 95% of all users of 
such a page, and I would argue that satisfying the remaining 5% 
would require a lot more effort than telling them "yum install 
yum-utils" and "repoquery --help".

Would that be a better idea?

Regards,
-- 
Konstantin Ryabitsev
McGill University WSG
Montréal, Québec