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.