#3454 Various issues with pkgdb application pages (outdated pkg versions and EOL Fedora releases, Fedora releases unsorted, misleading applications)
Closed: Fixed None Opened 9 years ago by nphilipp.

= bug description =
1. The pkgdb application pages for Firefox and GIMP (and probably others as well) show outdated version information. For Fedora 17, Firefox is reported to be version 12 while 14 is available as a stable update, GIMP is reported to be 2.8.0-RC1 while it's really 2.8.0 (final, and 2.8.2 soon). It can be especially harmful as the "application" view may well be what somebody who doesn't know Fedora uses to find out which versions are in the current Fedora release which may lead that person to not use Fedora if it lists an old version. This actually happened to somebody curious about Fedora today who was surprised to learn that F-17 does have Firefox 14 and not 12, which is why I'm reporting here.

  1. The application pages list old, EOL Fedora releases.

  2. The packages on the application pages are grouped per Fedora release. These are unsorted, for GIMP they are listed as f16, devel, F-13, f17, f14, F-12, f15, F-11, for Firefox it's a different order entirely.

  3. If you search for "gimp" in applications the first hit "Gimp" leads to the kdebase package in Fedora 12.

= bug analysis =
Just guesses:

  1. Missing or erroneous consolidation between bodhi updates and pkgdb applications.

  2. Data for EOL releases are still kept in the pkgdb applications database, no filtering is done.

  3. Release versions are displayed in the order they are returned from the DB, or a hash/dict or similar.

  4. The kdebase package shipped a desktop file in F-12 for kappfinder, probably with "Name=Gimp". I'm not sure if there is a quick way to block such erroneous entries in the pkgdb "applications" view (without hard-coding things in pkgdb code which results in a long time before it's rolled out).

= fix recommendation =

1. Near term: Regularly pull new updates (cronjob?), throw out old data (e.g. if desktop file data changes, or is moved from package A to package B).
2. Long term (HANDWAVY-FUTURE): Like 1.1., but push-based, triggered when a bodhi update is tagged into, or out of stable.

  1. Filter out EOL releases when grouping builds/packages.

  2. Sort Fedora release groups, e.g. chronologically from latest to oldest stable release, then devel.

  3. This should be dealt with by 2. already, if something like that ever happens again it would need to be dealt with on a case-by-case basis (e.g. to hide such an erroneous "application" which really isn't), perhaps this needs some code, prophylactically (HANDWAVY-FUTURE?).

Argh, markdown sucks for nested lists. The last three items should be on the outer level again.

The near-term plan is to migrate pieces of pkgdb's functionality (which is old and suffering from bitrot) over to the new "packages" webapp. For instance, your search for gimp would redirect to https://apps.fedoraproject.org/packages/s/gimp Furthermore, firefox has the correct version/build listed: https://apps.fedoraproject.org/packages/firefox

We have a wiki page documenting/brainstorming what pieces we want to move: https://fedoraproject.org/wiki/Pkgdb_migration

We intend for pkgdb to retain control over requesting and granting ACLs.

(We could definitely use an extra brain to help think over what we're missing.)

So, does ‚Äčhttps://apps.fedoraproject.org/packages/ address your concerns/issues?

As noted we are working on migrating off the pkgdb parts you mention... so, not sure what else is pending here.

Should we close this and continue with that work?

Closing after 5 months since last comment.

Login to comment on this ticket.