repoview + PackageDB (was Re: rawhide report: 20071127 changes)

Toshio Kuratomi a.badger at gmail.com
Thu Nov 29 19:49:35 UTC 2007


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




More information about the fedora-devel-list mailing list