Hi guys,
in my understanding, our current update procedure works like this:
1) We notice that a package was updated (or added) on Hackage by means
of RSS.
2) A maintainer runs cabal2arch to generate an updated PKGBUILD.
3) If the generated PKGBUILD looks good, the file is committed to the
Git repository and uploaded to AUR.
There are a few things worth noting about that procedure:
- A maintainer must perform 1 manual step per updated package: that is
linear complexity O(n).
- There is no mechanism to guarantee that the updated set of PKGBUILD
files actually works.
- It's common practice to use version control systems like Git to track
original source code. Our setup, however, tracks generated files: the
PKGBUILDs are produced automatically by cabal2arch. So why do we
track them? Shouldn't we rather track the Cabal files?
Naturally, one wonders how to improve the update process. There are a
few possible optimizations:
- The simplest way to verify whether all PKGBUILDs compile is to, well,
compile them. Given a set of updated packages, all packages that
directly or indirectly depend on any of the updated packages need
re-compilation, and the current set of PKGBUILDs is to be considered
valid only if all those builds succeed.
- It is possible to download the entire state of Hackage in a single
tarball. Given all the Cabal files, a Makefile can automatically
re-generate those PKGBUILDs that need updating. The same Makefile can
also run the necessary builds, and it also perform the necessary
uploads to AUR.
Based on these thoughts, I would like to propose an improved procedure
for discussion. Let our Git repository track a set of Cabal files. Then
an update would work like this:
1) A maintainer downloads
http://hackage.haskell.org/packages/archive/00-index.tar.gz
and extracts the Cabal files into a checked-out Git repository.
2) Optionally, inspect changes with "git status" and "git diff".
3) Run "make all" to re-build all PKGBUILD files that need updating.
4) Run "make check" to perform all necessary re-builds of binary
packages. If all builds succeed, proceed with (5). Otherwise, figure
out which package broke the build and revert the changes in the
corresponding Cabal file. Go back to (3).
5) Run "make upload" and "git commit" the changes.
Now, this procedure is supposed to update AUR, but "make upload" can be
easily extended to copy the generated packages into a binary repository
as well.
The worst case scenario occurs when every single available update breaks
during "make check". In that case, the procedure has linear complexity
O(n). The best case scenario, on the other hand, is the one where every
single update succeeds. That case is handled by running "make all &&
make check && make upload", which gives constant complexity O(1).
More importantly, however, the "make check" phase would guarantee that
we never ever publish a configuration that doesn't compile.
How do you feel about the idea?
Take care,
Peter