pkgbuild-watch - Follow upstream releases

keenerd · 2012-06-14 18:50:24

Pkgbuild-watch alerts you to upstream activity. Between AUR and TU duties, I have about 130 packages to look after and this checks all of them in 10 seconds.

AUR page: https://aur.archlinux.org/packages.php?ID=60011
Download: https://github.com/keenerd/pkgbuild-watch

It is meant for three types of people:

Maintainers. If you are a Dev, TU, or anyone with AUR packages, pkgbuild-watch will let you get updates out to your users faster.

Rebuilders. If you maintain your own source ABS tree, pkgbuild-watch will tell you when any Arch package gets an update.

Flaggers. Somewhere a maintainer is sleeping on the job. Find reasons to pester them with ease, though you'll still have to click the flag-out-of-date button yourself.

Use:

pkgbuild-watch /path/to/your/pkgbuilds

Path is searched for PKGBUILDs. If you have multiple paths (say for both AUR and ABS), create a dummy directory with symlinks to each.

The PKGBUILDs are all sourced (be careful with that!) and the $url is watched for changes. If the homepage url is not satisfactory, set the $_watch variable to the download page instead.

There are two magic values for $_watch. First is "none", useful for VCS packages. The second is "package". This uses the $pkgname to generate a link to http://www.archlinux.org/packages/, so that you can be notified when the Arch package is updated. (And it can untangle split pkgbuilds too.)

There may be some debate as to whether the $_watch variable should exist in the pkgbuild at all. I think it should, because it benefits everyone and seems the most sensible place to do this sort of thing. I would like to hope that someday this feature could become an official part of makepkg (losing the underscore in the process). We have Namcap to automate post-packaging, and pkgbuild-watch fills the pre-packaging void.

Xyne · 2012-06-14 19:06:04

keenerd wrote:

There may be some debate as to whether the $_watch variable should exist in the pkgbuild at all. I think it should, because it benefits everyone and seems the most sensible place to do this sort of thing. I would like to hope that someday this feature could become an official part of makepkg (losing the underscore in the process). We have Namcap to automate post-packaging, and pkgbuild-watch fills the pre-packaging void.

The intention here is good, but I object to adding third-party variables and code to PKGBUILDs. PKGBUILDs are already a mess in many cases. If people start including more code in them it will get out of hand.

I recommend building a database of URLs to watch instead. Keep it simple and use either a plaintext file (<pkgname> <watch url>\n) or an SQLite3 database. You can populate it automatically by sourcing the PKGBUILDs if you like and then let users manipulate it manually as necessary.

Of course, if you get upstream support for a new variable in makepkg then go for it. I see some potential use for it, but scraping a page for changes is not a robust approach and most projects will not offer a dedicated feed or API for such functionality.

keenerd · 2012-06-14 19:21:18

I pondered that for several days too. Ultimately I decided it was worth the risk. It saves a huge amount of time and saves a lot of duplicated work. If you don't like it, it is not being forced on anyone. (I'd also prefer to have it well field tested before trying to get official support in makepkg.)

$_watch is rarely needed in practice. Literally 9 times out of 10, the stock $url is good enough and you don't need any extra variables. For my 130 packages, there are only 11 which needed $_watch to avoid being spammed by irrelevant changes.

sitquietly · 2012-06-15 21:46:07

Xyne wrote:

keenerd wrote:
There may be some debate as to whether the $_watch variable should exist in the pkgbuild at all....
The intention here is good, but I object to adding third-party variables and code to PKGBUILDs. PKGBUILDs are already a mess in many cases. If people start including more code in them it will get out of hand.
I recommend building a database of URLs to watch instead....

I agree strongly that Arch pkgbuilds are getting messy; too many maintainers are writing code where there should (I think) be simple variable assignments. I don't mind another (clean, code-free) variable.

My motivation in arguing for cleaner pkgbuilds is this: I maintain a stable release of Arch / KDE. uh, well, I'm doing my second release To build a stable release it is necessary to work entirely from source code so that I can freeze the kernel level, the toolchain, and the core audio/video packages, and still build updated applications, until my analysis of the state of things tells me that its time to update the core and roll up to a new stable point (the gcc 4.7 change was made just last week and was painful -- many arch pkgbuilds will not compile with the new toolchain and require patches which I usually get from Debian sid or figure out myself). To do this properly requires keeping a database of all package info (versions, depends, makedepends, sources, groups, pkgbase). So I parse every pkgbuild from abs and aur. Gosh are they a mess to parse! My awk scripts for parsing out the required fields are a bit ugly because folks got out of the habit of writing simple statements like you would find in CRUX (from which Arch came). Now there are sometimes rather complex scripts calculating simple stuff like version numbers and release numbers. (It is not safe to source the pkgbuilds to get the assignments; sourcing all these pkgbuilds would do Unexpected Shit.)

My TED wish, "One Wish to Change the World", is for all Archlinux pkgbuilds to be simple and easily parsed.

I guess I AM a guy who needs to use pkgbuild-watch, I'm ending up being an independent maintainer of "Arch stable" and given my current level of frustration with Arch as a base I'm either going to get comfortable doing my own versions of some packages or I'm going to switch to Slackware or Debian. Arch happens to have a very good maintainer for KDE and the kde stuff is mostly as good as anywhere.

Thanks for the heads up on pkgbuild-watch!

Allan · 2012-06-15 22:01:09

keenerd wrote:

(I'd also prefer to have it well field tested before trying to get official support in makepkg.)

Not going to happen... This is irrelevant to package building so is not suitable for inclusion to makepkg.

BTW, I have use urlwatch for a long time to do this. It allows you to add lots of filters to remove crappy changes (like dates...).

Arch Linux

#1 2012-06-14 18:50:24

pkgbuild-watch - Follow upstream releases

#2 2012-06-14 19:06:04

Re: pkgbuild-watch - Follow upstream releases

#3 2012-06-14 19:21:18

Re: pkgbuild-watch - Follow upstream releases

#4 2012-06-15 21:46:07

Re: pkgbuild-watch - Follow upstream releases

#5 2012-06-15 22:01:09

Re: pkgbuild-watch - Follow upstream releases

Board footer