Alex Lancaster wrote:
"TK" == Toshio Kuratomi writes:
TK> Patrick Ohearn wrote:
On Tue, 2007-11-27 at 23:28 -0500, Build System wrote:
New package R-rlecuyer
R interface to RNG with multiple streams
Is there a web interface for checking different versions in
different repos, say like packages.gentoo.org and
packages.debian.org?
TK> You're looking for repoview:
TK> http://download.fedora.redhat.com/pub/fedora/linux/releases/8/Everything/i386/os/repoview/
Unfortunately repoview shows only a fraction of the information that
packages.debian.org and doesn't unify them nearly as well as
packages.debian.org does.
Most of the packages.debian.org information lives in the repodata,
though. So displaying the information in repoview seems like the
logical thing to do.
Things that repoview can't do:
* Create the links between repositories (present in x86_64, x86, but
not ppc)
* List the maintainer
* search
Everything else on packages.debian.org looks like it could be done from
repoview.
I think that PackageDB should ultimately become the equivalent kind of
"portal", because we have a proliferation of sites where various
package information is kept (bodhi, packagedb, koji, repoview) and it
would be nice to tie them in all together into a single package
"portal" the way Debian/Ubuntu does with all information about the
package in one location and fold the repoview stuff into it. You could
still keep the koji, bodhi web interfaces as they are, but have
PackageDB querying them and displaying all the latest information in
one place for each package. PackageDB has started this with the new
bugzilla interface, which is nice.
I go back and forth on just what the packagedb should be providing.
repoview has two advantages over the packagedb:
1) repoview is nice because it is static data. Therefore it is
lightweight to operate and canbe distributed to our mirrors.
2) repoview is updated when the repositories are updated from the
databases in the repository. Therefore it is just an extension of the
canonical data about what packages a user is going to be using. This is
especially important when thinking about subpackages, which the
packagedb doesn't know about.
OTOH, some things need to operate dynamically (search and ratings, for
instance) and some things are not present in the repo information
(maintainers, bodhi ratings, scratch builds, etc).
The ideal situation for the packagedb is to let repoview handle the
things its good at as much as possible while doing the things that
repoview can't do easily. For the end user, the ideal is to have a
seamless experience so they see themselves navigating amongst different
places on the Fedora Site rather than different sites within Fedora.
Figuring out how to balance these two is what makes the situation
interesting.
I have some notes on this here:
https://hosted.fedoraproject.org/projects/packagedb/ticket/79#comment:1
Yep -- anyone else interested in this, please join in -- I can help get
someone set up with a test instance if there are coders interested in
adding this information.
-Toshio
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
