I'm giving a talk called “Rehabilitating pkglint” later this month at pkgsrcCon, which means I need to do some work worth talking about. pkglint is a tool for pkgsrc developers to find common errors in packages. It's not part of pkgsrc infrastructure proper, but it's a key step in the package development cycle. And it has problems. One proposed solution is to rewrite it.

A rewrite may or may not be a good idea (I bet not), but in either case, the beginning of the solution to pkglint's problems is to first understand and document its current behavior. I've retrofitted (very cautiously) a place to put tests, along with a handful of test cases. A long road of adding coverage and safely refactoring lies ahead. To get as far as I possibly can by the 23rd, I need to be able to:

  • Work offline,
  • Make experimental and possibly outlandish choices,
  • Commit promptly each time one of those choices pays off, and
  • Not worry (yet) about having my changes reviewed and approved.

If pkgsrc were managed in a DVCS, I'd be good to go. Since it's in CVS, I did this:

$ echo .git >> ~/.cvsignore
$ echo CVS >> ~/.gitignore_global
$ cd .../pkgsrc/pkgtools/pkglint
$ git init
$ git add .
$ git commit -am 'Add pkglint to git for offline hacking.'
$ git checkout -b rehab

Now I'm tracking pkglint in its own little git repository. The master branch tracks upstream, and the rehab branch is where I hack:

$ cd .../pkgsrc/pkgtools/pkglint
$ git checkout master
$ cvs update
$ git commit -am 'Track upstream changes from pkgsrc CVS.'
$ git checkout rehab
$ git rebase master
$ vi files/pkglint.t files/pkglint.pl && make test && make clean
$ git commit -am 'More cool stuff on my branch.'

This is a slightly clever trick, but not too much so. I'm happy and productive with it so far.