From Fedora Project Wiki

Revision as of 16:29, 14 August 2012 by Toshio (talk | contribs) (Add response to whether tags are needed in pkgdb view.)

pkgdb code that needs migrating:

shows applications (anything that has a .desktop)

  • PackageDB web page
  • Database schema linking applications, download repositories, builds within the repositories, and the collections that are there.
  • Script to sync what's in the download repositories into the database
    • Script parses the file list for each package. If it encounters a .desktop file it flags that package as an "application", downloads the package, and extracts additional information -- icons, menu name, etc.

shows builds (binary rpm packages in the repositories)

  • Users wanted -- a view of what's in the download repositories with:
    • Ability to add metadata: rating tags
    • Ability to install from the web
    • Additional desires:
      • Wanted links to upstream (rpm's Url: tag)
      • Something similar to what upstream release monitoring does now (look at what versions are available upstream)

Idea: Consider https://admin.fedoraproject.org/pkgdb/applications/Geany -- we could remove the "Available Builds" section and have the link at the top instead redirect the user to https://apps.fedoraproject.org/packages/geany/builds and "be done with it".

allows rating and tagging applications

Requirement:

  • pkgdb exports a sqlite db of tags=>binary rpm names for each release that bodhi incorporate into yum repodata. /tagger needs to do that as well.

Ideas:

  • Do we need to keep Tags in the pkgdb view? We could simply remove Tags from the Application Info pane and provide a link next to "User Comments | Builds" like "User Comments | Builds | Tags" that redirect the user to https://apps.fedoraproject.org/tagger/geany
    • I'd like to more applications/builds/tags out of packagedb as a group. Removing only some of it doesn't buy us much. We still end up having to parse and store the same infomation -- we just wouldn't have a public interface to it anymore.

shows open bugz against a package.

Note.png
Maintainers love using this as an easy way to see all the bugs against their package. They have also asked for a bugs page on their pkgdb user page that would show them all bugs against packages that they own or comaintain or are on the watch list for.

The /packages feature that duplicates this is a little bit broken. It has to do with the busted multicall support that happened with the latest bz upgrade. It only fails for packages with "lots of bugs" like this one, https://apps.fedoraproject.org/packages/kernel/bugs