Eric Dorland: watch files considered helpful
I spent some time yesterday putting
watch files in most of my packages. Watch files have been around for a long time in Debian, but hasn't reached the exposure it perhaps deserve. They're used by uscan to check for newer upstream versions of the source. What's even more useful than running uscan is the Debian Watch Health Status pages (which are also helpfully linked from the QA developer's page, but that functionality appears to be broken at the moment) which parse the watch files as well and provide a nice web interface to look up your packages and others and see where upstream is at.
Unfortunately, for this to work properly the package needs a watch file, and according to the statistics, only 1/3 of all packages have watch files. So here's a quick tutorial, just plop a suitably modified version of these examples into the debian/watch file in your package and you're off to the races. If you're packaging foo and the source tarballs are on ftp.foo.org your watch file will look something like this:
version=3 ftp://ftp.foo.org/pub/foo/foo-(.*)\.tar\.gzSome things to note: the version line is just there to allow for future enhancements without breaking backwards compatibility. For the location specifier, the last part after the final
/ is a regular expression (notice the .'s are escaped). The pattern inside the parentheses is what gets parsed as the upstream version number. For HTTP the syntax is almost identical:
version=3 http://www.foo.org/files/foo-(.*)\.tar\.gzThis snippet will download
http://www.foo.org/files/ and look for href's corresponding to the rest of the pattern. For projects hosted on Sourceforge, there's a handy syntax for that, and uscan will take care of figuring out its annoying mirror system. If it's project bar, and the source is called libbar:
version=3 http://sf.net/bar/libbar-(.*)\.tar\.gzThere are many more details in the
uscan man page. I think it would be great if more maintainers put watch files in their packages. It's one of those touches that really sets Debian apart from the rest.
The future for Ruby and Emacs is looking hopeful. I learned that a
proper Ruby grammar for the semantic package is being worked on,
which will enable class browsing and intelligent completion.
I am still disappointed that there's no version of Emacs
that uses Xft or Pango for anti-aliased font rendering. To get sharp fonts,
I still need to use a bitmap font like misc-fixed. If I were in the
business of offering bounties for open source development, dragging
Emacs into the GTK2/Pango era would be the biggest one.
Checking the mailing lists indicates that