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 (5)
Created 2 months ago,
accepted
- The project needs to be split into multiple projects
- Comment:
so it appears we have two active forks that keep "leapfrogging" each other in versions: duncaen and slicer69. Can they be officially split into 2 separate packages?
Created more than a year ago,
rejected
- Comment:
What about the fact that *ONLY* freebsd is using slicer? Every other platform is using OpenDoas. Why does freebsd get precedent here?
Plus, the author has stated that Duncaen is the successor. It looks like freebsd maintainer just picked a random fork which unfortunately repology is signaling is the "correct" one.
- Repology reply:
> What about the fact that *ONLY* freebsd is using slicer?
Why does this matter? They may use whatever they want, as long as it doesn't make original release outdated
> It looks like freebsd maintainer just picked a random fork which unfortunately repology is signaling is the "correct" one.
What makes you think it is incorrect?
Created more than a year ago,
rejected
- Comment:
slicer69 last commit: 11 october 2017
Duncaen/OpenDoas (the official successor to nholstein/OpenDoas): 6 Apr 2018.
OpenDoas is newer, slicer is not the development path, just a (stagnant?) fork
However, as it is currently, 6.0 is showing as latest, which is the correct information, even though it is sort of accidental.
- Repology reply:
But Duncaen's 6.0 is from 2016, so slicer69 _does_ have newer release. If Duncaen releases new version though, slicer69 would become outdated. It looks correct to me.
Created more than a year ago,
accepted
- Comment:
Thanks for the merge. However, the slicer69 version of 60.p2 is showing as newer than the opendoas version of 6.0. Only FreeBSD family is using slicer. In my opinion, packages based on opendoas should be considered the latest, not FreeBSD.
- Repology reply:
Well it actually IS newer than opendoas. I'm marking it as devel.
Created more than a year ago,
accepted
- Comment:
This one is interesting.
"opendoas" should be merged into this one.
However, there are forks involved here.
The "true" version was https://github.com/nholstein/OpenDoas, but it passed the torch to https://github.com/Duncaen/OpenDoas which should now be considered the standard.
FreeBSD family uses https://github.com/slicer69/doas/.
(ravenports currently does as well, but will move to OpenDoas").
So I'm not sure if freebsd should be handled differently. There are multiple version schemes here.
Slicer69 has a proper release at 6.0p2. The OpenDoas does not have releases, so people are just picking different hashs and calling it "6.0". Like I said, a mess, and not sure what the best arrangement is.
New report