À 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@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
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
