Add package grouping to metapackage pages

repology / repology-webapp

Repology web application

https://repology.org

GNU General Public License v3.0

193 stars 26 forks source link

Add package grouping to metapackage pages #44

Open AMDmi3 opened 5 years ago

AMDmi3 commented 5 years ago

There are projects with lots of packages (haha) which are too clumsy to display on a single page. Grouping should be introduced into many places:

Versions page

Merge rows which differ only with package name and/or version. E.g. group by repository+category+maintainer first, then there are multiple options which need to be investigated.

May emit a single row with a list of package names and a list of versions in corresponding cells. This is the simplest, but it removes the relating between names and versions.
Emit row per name with a list of versions
Emit row per versions with a list of names (this looks like the best now)
Emit either of the previous two based on which produces less rows

Additionally, limit long lists with e.g. 10 entries, add a popup with full list. Or add a per-repository page without grouping.

Packages page

TBD

Information page

TBD

AMDmi3 commented 5 years ago

Tried generic approach to package grouping on Versions page: packages are sorted by version, then name, and adjacent packages are grouped if they only differ by version or name. The grouping works very nice, collapsing both cases similar to "language packs" where there are like 100 packages with the same version, and wikidata which has like 100 versions for the single package.

However I don't like results from the usability point of view - large blocks of similar package names are unreadable, they are wrapped inadequately by browsers, they do not conserve much vertical space and they produce a lot of unused space too (e.g. other columns).

The next idea is (instead of grouping package names/versions in the single column) to use a whole row and place repeated data there. Might have problems with row coloring (e.g. even/odd) messed up.

AMDmi3 commented 4 years ago

We need to start with just removing duplicates

PureTryOut commented 4 years ago

Could this be extended to group "group releases" like the KDE Release service packages? That is a group of 100+ packages which all get updated at the same time a few times a year. Once any distro has packaged the new release, my maintainer page is immediately unusable as it's filled with packages from the KDE release service, which all just have the same new version.

It would be nice to have it grouped into a single "KDE Release service" and only show individual packages when their version differs from the rest of the group. I can imagine there are more projects that release updates like this.

AMDmi3 commented 4 years ago

What exactly do you mean by your "maintainer page" and "unusable"?

PureTryOut commented 4 years ago

Ah sorry, the page that lists per maintainer which packages they maintain are outdated.

Unusable is not really "unusable", but the list is just filled with KDE Release service applications, even though I need to know for just one if it's outdated or not to know for them all they're outdated. I can still use the list of course, but it takes lots of going through pages to find non-KDE packages that I have to do something for.

AMDmi3 commented 4 years ago

Moved to a separate issue for this is not really related to this one (grouping of package entries for a single given project).