"packages.gentoo.org":http://packages.gentoo.org has long had two "minor" problems displaying package data.

One was that when you display data about a package you want to tell what license the package is under. But licenses are related to individual ebuilds and not the package. The current way of doing it is that the 'license' column is in the 'package' database. What license is displayed for a particular package is whatever license data was applicable for the last updated ebuild. This is an innacurately portrays the package. The simple solution is to remove the 'license' column from 'package' add it to 'ebuild' and only display the license data for the particular ebuild. When a user is looking at a package he/she will need to select a particular ebuild to see that package.

The problem I've always had with that is, usually when people talk about licenses they talk about packages not particular versions of packages. People want to know what package 'xchat' uses, not what license 'xchat, version x.y'. So it would be bad not to display that information with the package as well as the ebuild.

The solution I chose for the new packages.g.o (P2) is to have the package page display the union of the licenses for all the ebuilds as this "illustration":http://starship.python.net/crew/marduk/files/licenses.jpg shows.

The other issue is with home page updates. packages.gentoo.org only updates the home page when there is a "new" ebuild, basically new revisions and version bumps. However, sometimes the home page for a site changes when there is no new updates. The portage devs make changes to the ebuilds, but there are no bumps, so the package.g.o database never gets upgrades. It's inconvenient for the user because the database is not reflecting current data, but it is also inefficient to have to look at every ebuild during the update interval to see if the home page has changed. My solution for this is to have a utility script that will less periodically (say twice a day) update the package database to reflect the home page of the most-recently update ebuild for a given package. This code will also eventually find it's way in P1.

Since these two items are the bulk of the bugs and complaints I hear about the site, I hope this will satisfy most people's wishes.

Now for dependencies and 'USE' flags...