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

Revisit package name display on the site #92

Open
AMDmi3 opened this issue Nov 13, 2019 · 0 comments
Open

Revisit package name display on the site #92

AMDmi3 opened this issue Nov 13, 2019 · 0 comments

Comments

@AMDmi3
Copy link
Member

AMDmi3 commented Nov 13, 2019

After latest changes in package name handling (e.g. introduction of new kinds of names, some fields becoming optional) we may want to revisit name handling across the webapp. A quick summary where (some kind of) names are used:

  1. project/versions (package name, also sorting) - visiblename currently
    • the primary purpose of package name here is to visually identify which package a version relates to (note that there's also a link in most cases). We're probably OK with what we use now, e.g. primarily source names for repositories and titles for other sources. However, we still very much need Add package grouping to metapackage pages repology-rs#104 to avoid duplicate entries due to different binary package names.
  2. project/packages (package name) - visiblename currently
    • names no longer identify a package (and also may be quite long), so we may move them out of the panel headers, and explicitly list source package name / binary package name, but we need a consistency in how we represent them (as the real meanings are more closer to source names we use in repology-updater's NameMapper - there are titles, IDs, items, FMRIs, recipe/source/binary package names etc.) - may save this information in repository metadata
  3. project/information (list of names) - visiblename currently
    • visiblenames now mean different things for different sources, so it doesn't make much sense showing them in a single list (3) - may consider removing the list completely. This would also help with a lot of i18n entries
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

1 participant