Interesting statistics about solus repository

kaliangel

I found a site listing hundreds of repositories of different distributions. The Solus repository is also listed and there are some interesting statistics. It is also a good way to see the extent of the work done by the mainteners.

https://repology.org/repository/solus

algent

kaliangel It is one of my top sites.

DataDrake

kaliangel fwiw, there are a fair number of packages that we intentionally held back that are being reported as out of date. Especially Haskell which I know is way behind. As well as things like GNOME 3.25 that we would never update to anyways, being an odd-numbered (development) release. That's in addition to the ones that we haven't gone through deprecating yet.

DataDrake

They are also only looking at Shannon, not Unstable so there stats will only be really useful right after a sync for normal users.

algent

DataDrake In fact they are looking on Unstable.

DataDrake

algent Not sure where you are seeing that.

aleksvor

DataDrake
https://github.com/repology/repology-updater/blob/8afa7d570c44e970237d939ba7789ec2cc4efede/repos.d/solus.yaml#L14
I can see that in their sources. They parse eopkg-index.xml.xz from Unstable to get info about packages.

Justin

I've used this many times in the past, the owner is often reluctant to fix things as many distros run on unstable releases as DataDrake said, 3.25 (odd) releases of GNOME.

Harvey

It's neat but limited in its usefulness.

Maintainers:
Users should not care who the maintainer is but the information is useless regardless because it goes on whoever touched it last , it does not look at the MAINTAINERS.md file. Which means I am incorrectly listed as maintainer of gourmet, deadbeef and rxvt-unicode just because I fixed something, those packages don't have a dedicated maintainer.

Also when a rebuild is required that does not always get done by the packages maintainer so the statistics of the number of maintainers is useless too.

Problematic packages:
Are not problematic. Lynx uses a dumb versioning system. 2.8.9rel1 we call 2.8.9.1 big who cares.

Out of date packages:
Not an issue Solus is a rolling release that does not focus on bleeding edge. Also things can and are often held back for good reasons as has already been discussed.

But yeah neat.

brent

Harvey you fixed gourmet for me (thanks) but I knew you weren't the maintainer. that's why I like the transparency of our own SC change log much better: it's apparent there's a dedicated committee (triage) overseeing/initiating fixes more or less. At the end of the day it's a team effort with someone signing off on the latest. As far as industrial protocol, this is entirely normal.
PS: as a part-time user, yes, Lynx is weird but funtions🙂
edit: verbiage fwiw

Harvey

brent
No worries, enjoy it while it lasts gourmet has seemingly made no progress on switching to python3 and with python2 being EOL already it will get nuked eventually.

brent

Harvey no worries and thank you. recipe databases come and go!

kyrios

I had a quick look at this and... meh... it's more confusing than helpful at this stage.

For example brother packages are up-to-date but they are flagged as outdated because for some reason it adds an _1 in its version.

Calibre 4.10.1 is currently the latest stable version but they get another

eid-mw 4.4.21 is the latest version tagged for linux. It seems some distros updated to 4.4.23 which is a windows tagged version (this doesn't surprise me from Arch but obviously 4 distros updated to that version). And the latest version is actually wrong since it is 4.4.25 (released on Dec 11th, 2019, again for windows).

At this stage it is really too inaccurate to be of any use. It shows a wrong picture of the reality.

Justin

From the page:

This (Solus) repository does not provide homepage information in a way accessible by Repology. This is critical, because homepages are used to resolve project name conflicts, e.g. to distinguish similarly named packages of unrelated projects. Because of that, this repository is subject for removal in the near future.
See documentation for a best way to make package metadata accessible for Repology.