Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add package grouping to metapackage pages #44

Open
AMDmi3 opened this issue Oct 4, 2018 · 6 comments
Open

Add package grouping to metapackage pages #44

AMDmi3 opened this issue Oct 4, 2018 · 6 comments

Comments

@AMDmi3
Copy link
Member

AMDmi3 commented Oct 4, 2018

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
Copy link
Member Author

AMDmi3 commented Feb 21, 2019

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 referenced this issue in repology/repology-updater Aug 25, 2019
...to not spawn duplicate packages until #711 is implemented and arch field is used anywhere
@AMDmi3 AMDmi3 transferred this issue from repology/repology-updater Oct 4, 2019
@AMDmi3
Copy link
Member Author

AMDmi3 commented Nov 13, 2019

We need to start with just removing duplicates

@PureTryOut
Copy link

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
Copy link
Member Author

AMDmi3 commented Sep 7, 2020

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

@PureTryOut
Copy link

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
Copy link
Member Author

AMDmi3 commented Sep 7, 2020

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

AMDmi3 added a commit to repology/repology-updater that referenced this issue Sep 28, 2022
We need it to generate packagelinks in some cases (Arch, for
instance). Despite what the comment says, it should not lead to
package lists blowup on the site as arch is not currently queried
and used there.

Related #1274, repology/repology-webapp#44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants