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,
Comment: distrowatch has listed 2.6.3 as the latest libressl, and it's simply not true (at the time of this writing)
It even provides a link which doesn't work (because 2.6.3 hasn't been released).
I've seen this sort of thing with distrowatch before, where they report a release before it happens.
I'm starting to question the value of this repo, especially if false positives become common.
Repology reply: Mailed distrowatch, they have fixed this
Created 2 years ago,
The project needs other projects merged into it
Comment: I'm not sure what to recommend here.
There are two metapackages: libressl and libressl-devel
There are many repos matched to libressl showing version 2.6.0 which should be libressl-devel.
Alternatively, libressl-devel should be merged in libressl to form a single metapackage, but that isn't great either. Anyway, there's an issue here.
Repology reply: libressl-devel merged, for unstable version see https://github.com/repology/repology/issues/316