floss.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
For people who care about, support, and build Free, Libre, and Open Source Software (FLOSS).

Administered by:

Server stats:

686
active users

#Repology only has marginal support for F-Droid, only seeing a few handpicked packages for software which is also available in Linux:

repology.org/projects/?inrepo=

I've recently had a few PRs which improve F-Droid support and add #IzzyOnDroid, allowing full-fledged version comparison within Android ecosystem.

I wonder if any #fdroid maintainers or @IzzyOnDroid would be interested in that.

repology.orgProjects list - RepologyMultiple package repositories analyzer

@AMDmi3 i can check when i'm back at my desk next week. What would you need from us to support repology for IzzyOnDroid?

@IzzyOnDroid nothing really - just a feedback. Here's, for instance, list of projects in IzzyOnDroid which intersect with other repos (F-Droid, that is, but I am still to recheck if there are any projects which also intersect with *nix repos)

repology.org/projects/?inrepo=

repology.orgProjects list - RepologyMultiple package repositories analyzer

@AMDmi3 PS, just another thing I found: dev.jahidhasanco.bmicalculator at F-Droid is a different package than at IoD (coming from different repositories, thus should not have the same packageId; actually their 4.0.2 is OLDER than IoD's 1.0.3 (theirs is 4 years old, ours 1 year). Not sure which should be marked "outdated" there. Comparing the source URL might help detect such things.

@IzzyOnDroid sure, Repology has facilities to split similarly named projects (and I've in fact seen more cases of this problem), but these imply expanding manually maintained ruleset, and that has its cost. So I'm asking for a feedback - if that's not useful for either IoD or F-Droid, it would make sense to cut the maintenance cost and hide android-specific projects in Repology.

@AMDmi3 Umpf. Never go by the display name I guess: repology.org/project/android:c is different repos and different package names, there are probably hundreds of apps named "Calculator"… or "Clock" repology.org/project/android:c (and without looking: "Notes"), or "Editor" (repology.org/project/android:e), also some Counter (repology.org/project/android:c). I guess packageName + sourceURL should both match to compare versions. Lots of false positives otherwise.

repology.organdroid:calculator package versions - RepologyList of package versions for project android:calculator in all repositories
IzzyOnDroid ✅

@AMDmi3 You use the old XML index, not the newer JSON? There are already 2 newer formats (JSONv1 & JSON-v2 index). Not sure if XML might be dropped one day. In the XML index, it is "<application id=" that gives you the packageName / applicationId. In JSON-v1 it is "packageName", in JSON-V2 the index key of "packages".

@IzzyOnDroid I've had no idea that there are newer formats. F-Droid parser (reused for IoD) haven't had major changes since 2016 when it was introduced. Guess it's time to revisit it.

Cannot check out the data right now, but if names you mention are these `org.example.calculator` like ones, I'd prefer to stick with display names - these at least have a chance to match with other ecosystems, fulfilling Repologys goal. Mismerged projects with common names can be split by URL.

@AMDmi3 I don#t know what parser you mean, but in 2016 there was only the XML index (aka "v0") – and meanwhile v1 and v2 have been released which differ a lot. Not only they are JSON instead of XML, but a lot of internals have changed or were added.

You should definitely not go by display names alone, that's pretty error prone in most cases. Those packageNames/applicationIds are supposed to be unique – but I understand they don't exist with many desktop apps. URLs should often help, yeah.