search

shutter-project / shutter

Screenshot tool for Linux
https://shutter-project.org/
GNU General Public License v3.0
537 stars 35 forks source link

repology.org | Problems in Wikidata #473

Closed Ricky-Tigg closed 2 years ago

Ricky-Tigg commented 2 years ago

Hello. In its current configuration, Repology, an on-line service aimed to be a packaging hub, gets its information associated to packages from a unique source – Wikidata. Thus that very dependency makes it unreliable, as the information it gathers can at best be as in-accurate as the one that is present in that source. As a consequence, are present there package versions having been assigned wrong label colour codes.

legend | label colour codes involved in issue

repology org_label_colour_codes

The component shutter currently illustrates that case. Its maintenance takes place at page. Components whose definitions are erroneous are reported.

Photon89 commented 2 years ago

Are you referring to the fact that in some repos an outdated version is marked as legacy?

Ricky-Tigg commented 2 years ago

That the issue, reported as "Homepage link http://shutter-project.org/ is a permanent redirect to its HTTPS counterpart https://shutter-project.org/ and should be updated.", might be the cause of wrong labels assignment.

"

Photon89 commented 2 years ago

I changed the URL at https://www.wikidata.org/wiki/Q18088089, let's see when repology picks up the change!

DarthGandalf commented 2 years ago

FTR, you don't need us to update wikidata :) It being a wiki, anyone can edit it

Photon89 commented 2 years ago

Looks like repology has picked up the change, as Shutter is not on the error list any more, but this did not affect the version numbers. Actually, the Wikidata entry only contains three version numbers which are all outdated, so I don't think that it is the actual information source where Repology takes its data from...

DarthGandalf commented 2 years ago

Can you explain what is the exact issue you think there is? Because repology looks correct to me.

DarthGandalf commented 2 years ago

there package versions having been assigned wrong label colour codes.

Are you saying 0.99.2 is not the latest version, or?

DarthGandalf commented 2 years ago

Ah, yeah, that number 2 just means that 2 repositories (across various linux distros etc) have version 0.99

Though that number is inconsistent with what I see in https://repology.org/project/shutter/versions - that page lists 4 repos with 0.99, but in yellow color which means the same repos also contain newer versions. Anyway, that's repology issue.

Photon89 commented 2 years ago

Well, it all looks good, the only thing in question is how the label "legacy" version is to be handled. Some versions are marked as legacy in one distro and outdated in another (say, version 0.93.1 is legacy in Fedora 31 but outdated in Fedora 30). But maybe this is just distro specific thinking which should not be touched by upstream.

DarthGandalf commented 2 years ago

Fedora 31 has 2 versions Выделение_426

This is why the older of these 2 versions is "legacy"

Photon89 commented 2 years ago

Ah, I see! Well, then everything is consistent. Though I wonder why some distros keep outdated versions as legacy alongside more recent version. :smiley:

DarthGandalf commented 2 years ago

For example, Gentoo does it for 2 main reasons

  1. When a new version is added, it's not marked as stable on any architecture yet Выделение_427

Here, Krita 5.0.2 is marked as stable on amd64, but 5.0.8 is marked as testing (~). And it's testing on several other arches. After a while, when the package was in testing at least for a month, it can be added to stable on that arch, and if the arches match between 2 versions, the older one can be deleted.

Normally, the old version is removed as soon as new version is stabilized, but as I don't have direct access to gentoo packages, opening a PR which just removes the old version is too much overhead for not much benefit. I usually bundle such removal with other changes to the package, e.g. adding a new version.

  1. If the old version is still available, it's easier to locally revert to it if the new version has some bug. Installing a version not from repo is possible, but more difficult.

There are more complicated cases, when several versions can be installed in parallel: Выделение_428

Here you can see that GCC 11 has different architectures marked as stable on the versions which are newer than the oldest available 11, so that version can't be deleted yet. OTOH, 10.3.0-r2 probably can be deleted already.

Well, then everything is consistent.

Except for the search page linked at first, which turns legacy versions also red, and shows a different number there. I counted 4 repos with 0.99, not 2.

Photon89 commented 2 years ago

@DarthGandalf I see, thanks for the explanation! In Arch Linux there is the tool "downgrade" which has access to several previous versions of any given package using the so called Arch Linux Archive, but these versions aren't accessible directly through the package management: https://wiki.archlinux.org/title/Arch_Linux_Archive

DarthGandalf commented 2 years ago

Actually, yet another reason is that it's possible to depend on some particular version of the dependency. E.g. >=dev-cpp/foo-2.0 or <dev-cpp/bar-3.0, then the package manager will have to satisfy such constraints to select a version for every package