While repology tries its best in matching packages across different repositories, this is quite a complex task:
- Packages of a single software project may be named differently in some repositories (for instance, libagg vs. agg, dungeoncrawl vs. dungeon-crawl, fonts-linuxlibertine vs. fonts-ttf-linuxlibertine vs. linux-libertine-fonts vs. linuxlibertine-fonts-ttf).
- There may be multiple unrelated software projects with a same name (for instance, clementine is both X11 window manager and a media player).
- Some packages may use incorrect versions (for instance, picking "next" version number which was not released yet when packaging a git snapshot, or using dates and commit hashes instead of version numbers).
Repology uses a set of manually edited rules to resolve these cases. You may submit a change to the ruleset directly or use this form to suggest an improvement to the ruleset. Please only use this for for problems which may be fixed by the ruleset (which are basically problems listed above).
Current reports (2)
Created 2 years ago,
accepted
- Comment:
so there seems to be 2 groups here: the old official version group (2.3, 2.4) and the "build from snapshot group". The latter group is in theory a "dev" branch, but there's no single versioning scheme for it. So it might be a good idea to ignore all versions longer than "2.4".
Created 2 years ago,
accepted
- The project needs some version(s) to be marked as ignored
- Comment:
This one is a mess. There was never a release after 2.4, but the last commit on the git repository was dec 23 2015, commit tag fa8646d
as a result, there's no particular trend on the versions.
Probably the versions are just dates (e.g. 20151223 and 2015-12-23) should be ignored
versions that reference the git tag should be ignored
maybe the best approach is to filter out "2.4" and "20DD[01]D[0123]D" to consider latest version as 2.4.20151223
Or maybe *every* version should be ignored? The best approach here is unclear.
New report