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