repoview + PackageDB

[Alex Lancaster]

>>>>> "TK" == Toshio Kuratomi  writes:

[...]

TK> Most of the packages.debian.org information lives in the repodata,
TK> though.  So displaying the information in repoview seems like the
TK> logical thing to do.

TK> Things that repoview can't do: * Create the links between
TK> repositories (present in x86_64, x86, but not ppc) * List the
TK> maintainer * search

TK> Everything else on packages.debian.org looks like it could be done
TK> from repoview.

The problem with repoview view is that there's no way to search or
list for packages across branches, in packages.debian.org you can
search for "say" bioperl:

http://packages.debian.org/search?keywords=bioperl&searchon=names&suite=all&section=all

and get a list of the versions of packages in each branch.  Also each
package has a source page here:

http://packages.qa.debian.org/b/bioperl.html

To my mind, this could live in PackageDB with the current version
underneath each branch in:

https://admin.fedoraproject.org/pkgdb/packages/name/perl-bioperl

It would say something like:

Collection   Owner   QA Contact  Status   Current version  Testing version

Fedora devel alexlan             Approved 1.5.2_102-8.fc7  N/A

Another thing missing from repoview is the list of dependent packages,
see, e.g.,

http://packages.debian.org/stable/science/bioperl

[...]

TK> I go back and forth on just what the packagedb should be
TK> providing. repoview has two advantages over the packagedb:

TK> 1) repoview is nice because it is static data.  Therefore it is
TK> lightweight to operate and canbe distributed to our mirrors.

TK> 2) repoview is updated when the repositories are updated from the
TK> databases in the repository.  Therefore it is just an extension of
TK> the canonical data about what packages a user is going to be
TK> using.  This is especially important when thinking about
TK> subpackages, which the packagedb doesn't know about.

TK> OTOH, some things need to operate dynamically (search and ratings,
TK> for instance) and some things are not present in the repo
TK> information (maintainers, bodhi ratings, scratch builds, etc).

TK> The ideal situation for the packagedb is to let repoview handle
TK> the things its good at as much as possible while doing the things
TK> that repoview can't do easily.  For the end user, the ideal is to
TK> have a seamless experience so they see themselves navigating
TK> amongst different places on the Fedora Site rather than different
TK> sites within Fedora. Figuring out how to balance these two is what
TK> makes the situation interesting.

Yes, what really matters is not exactly where the data is but how it
is presented to the users, if PackageDB is a seamless experience for
both users of Fedora as well as package maintainers, then it doesn't
really matter where the data is (but it should *feel* like a single
site).

Alex