Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#34447 - {archweb} Mark outdated packages automatically

Attached to Project: Arch Linux
Opened by Anatol Pomozov (anatolik) - Sunday, 24 March 2013, 19:47 GMT
Last edited by freswa (frederik) - Sunday, 13 September 2020, 13:48 GMT
Task Type Feature Request
Category Web Sites
Status Assigned
Assigned To Jelle van der Waa (jelly)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No

Details

It is a follow-up for discussion in pacman-dev https://mailman.archlinux.org/pipermail/pacman-dev/2013-March/016850.html

One thing that can be improved in Arch project is how out-of-date packages are discovered. Currently it is done by users who go to https://www.archlinux.org/packages/ find the package and then click "Flag Package Out-of-Date" link. Why to bother users? Why not to let some bot to visit websites and check for new versions?

There are examples of package managers that have such functionality - macports http://guide.macports.org/chunked/reference.livecheck.html Their Portfiles can have information about how to find released files (using regexp). Then periodically (e.g. daily) a bot visits webpages, parses html and checks if new files are present.
This task depends upon

Comment by Anatol Pomozov (anatolik) - Tuesday, 26 March 2013, 15:39 GMT
In theory the bot can use "source" field of PKGBUILD. e.g. source looks like

source=("http://download.savannah.gnu.org/releases/$pkgname/$pkgname-$pkgver.src.tar.gz"{,.sig})

It can extract the archive url

http://download.savannah.gnu.org/releases/$pkgname/$pkgname-$pkgver.src.tar.gz

and then try to probe newer $pkgver. e.g. current $pkgver is XX.YY.ZZ so it can try XX.YY.ZZ+1, XX.YY+1.0, XX+1.0.0 it should cover most project upgrades. There are some cases when version is not numeric one e.g. includes -alpha, -beta -rc, or some other versioning.
Comment by Anatol Pomozov (anatolik) - Thursday, 18 April 2013, 13:37 GMT
Hi, I have a script that checks versions. It is almost done and I'll send one to arch-general in a few days.
Comment by Anatol Pomozov (anatolik) - Thursday, 18 April 2013, 18:35 GMT Comment by Anatol Pomozov (anatolik) - Monday, 22 April 2013, 00:48 GMT
Hi, Dan.

Do you need any help with the task? I implemented the pkglivecheck script and I can share experience and thought with you.

I think to implement this task we need 3 things:

1) A ./pkglivecheck.sh script in makepkg or some other standard package. The script will be run by TU to find out-of-date packages. It is similar to my *.rb script but should be probably rewritten as it seems that shell is the standard language for tools in Arch.

2) By default livecheck script should use the algorithm described above. But there are a plenty of packages that do not follow the release version numbering. See https://mailman.archlinux.org/pipermail/pacman-dev/2013-April/017048.html for more info. We need to add some a special field/function to such PKGBUILD that will describe how to find current released version. Something like

livecheck() {
curl -s http://www.greenwoodsoftware.com/less/ | grep -Po "The current released version is less-(\d+)" | grep -Po "\d+"
}

it will parse home page for 'less' project and extract current version. If it does not match version in PKGBUILD then some warning is printed.

3) Write a cron job that will run ./livecheck.sh periodically and marks packages out-of-date on archweb.



What do you think?
Comment by Jelle van der Waa (jelly) - Wednesday, 09 January 2019, 21:59 GMT
Repology, https://release-monitoring.org/ and nvchecker and urlwatch are all options for OOD notifications.

Loading...