>>>>> "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§ion=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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
