Hi everyone! I have just written a little utility that fetches the list of maintained packages from build.opensuse.org and then it checks on repology if the package is outdated or not. For now it works only on Devel projects. Posting to get some feedback and checking if there is already some other utility that does the same. https://github.com/danyspin97/osutil Regards, Danilo
On Friday 2021-07-16 18:23, Danilo Spinella wrote:
Hi everyone!
I have just written a little utility that fetches the list of maintained packages from build.opensuse.org and then it checks on repology if the package is outdated or not.
So, can't you just ask repology.org for all packages of openSUSE TW (my definition of "maintained"), and get effectively the same response but querying one less service?
On Fri, 2021-07-16 at 18:26 +0200, Jan Engelhardt wrote:
On Friday 2021-07-16 18:23, Danilo Spinella wrote:
Hi everyone!
I have just written a little utility that fetches the list of maintained packages from build.opensuse.org and then it checks on repology if the package is outdated or not.
Great stuff! Thanks Danilo
So, can't you just ask repology.org for all packages of openSUSE TW (my definition of "maintained"), and get effectively the same response but querying one less service?
you mean something like the overview at https://repology.org/repository/opensuse_tumbleweed where out of 14609 packages, 3197 are marked outdated? or then drilled in to https://repology.org/projects/?inrepo=opensuse_tumbleweed&outdated=1 To see those outdated packaegs? having a CLI that uses this information to help users maintain their apps is defintiively a good thing. We should probably even try to further integrate this into the osc- collab server version information tool: https://github.com/openSUSE/osc-plugin-collab Cheers, Dominique
Am Samstag, 17. Juli 2021, 10:11:24 CEST schrieb Dominique Leuenberger / DimStar:
having a CLI that uses this information to help users maintain their apps is defintiively a good thing.
Please keep in mind that some packages may be 'outdated' by purpose - they may e.g. stick to an LTS version or similar. (I had in special the tryton* packages in mind) Cheers Axel
On Sat, 2021-07-17 at 10:39 +0200, Axel Braun wrote:
Am Samstag, 17. Juli 2021, 10:11:24 CEST schrieb Dominique Leuenberger / DimStar:
having a CLI that uses this information to help users maintain their apps is defintiively a good thing.
Please keep in mind that some packages may be 'outdated' by purpose - they may e.g. stick to an LTS version or similar. (I had in special the tryton* packages in mind)
Absolutley! The decision about when to do an update should remain with the respective maintainers. The tooling should only be usable to TELL that there is a potential update available. Not having it done can be well within the parameters to deliver a stable experience. And we also need to take into account how repology decides what 'the latest version' is. Which seems not exactly in relation to what any given upstream does (e.g. cutecom, repology claims 0.51.0+patch would be the latest version. just because one distro decided to define this as version number for their 0.51.0 package) So, the tool can HELP to make a decision, but it cannot make the decision for us. Cheers, Dominique
Yes they use the latest (highest) version number a distro uses as the version. Sometime you have to flag a version number as invalid (should be ignored), because some distributions use custom versions not matching the upstream. E.g. 1.2.3 if upstream is 1.2 but there package revision is 3. But basically repologys requires that the version matches the latest git tag (or similar proof). Cheers Ferdinand Am 17. Juli 2021 11:07:03 MESZ schrieb Dominique Leuenberger / DimStar <dimstar@opensuse.org>:
And we also need to take into account how repology decides what 'the latest version' is. Which seems not exactly in relation to what any given upstream does
(e.g. cutecom, repology claims 0.51.0+patch would be the latest version. just because one distro decided to define this as version number for their 0.51.0 package)
participants (5)
-
Axel Braun -
Danilo Spinella -
Dominique Leuenberger / DimStar -
Ferdinand Thiessen -
Jan Engelhardt