repoview + PackageDB
alexl at users.sourceforge.net
Thu Nov 29 22:09:00 UTC 2007
>>>>> "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:
and get a list of the versions of packages in each branch. Also each
package has a source page here:
To my mind, this could live in PackageDB with the current version
underneath each branch in:
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,
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
More information about the fedora-devel-list