Just to let everyone know, I expect to finish publishing the current releases during the day Friday. Both 8.3.9 and 8.4.2 are built with the major UTF8 and Johab bug fixed. At this point, the changes to address an issue with collation on Mac OS X (shared by all of the BSD based variants as far as I know) are being held back until we get more testing done on the changes.
A huge part of the delay is that the build process for this distribution is a very time consuming process, and the 8.4.x tree has really caused the old automated system fits. I guess in order to explain this properly we need to shed some light on the whole process.
Building PostgreSQL for Mac as a distribution is 8 separate iterations of the build for each version. 2 iterations each on 4 different machines. Complex? that's the easy part. Once all of the iterations are run, they have to be stripped and reassembled as universal binaries, merged from all of the build iteratations. Then the finished product has to go back to each of the 4 machines to test the finished product. The reason for this is quite simple. If you don't build on the architecture you want to run on, the build process makes decisions based upon the current architecture. That can and will cause unexpected behaviors in the resulting binaries (like endian issues, or header files without out of order data structs).
The current setup has a 10.4.11 Mac Mini G4 as the 32bit PPC build box. Then old semi-retired PowerMac G5 running 10.5.8 does the 64bit PPC build. For the 32bit x86 (i386) build, we have a 1st generation Intel iMac running 10.5.8 and finally for the x86_64 build we have either a LED 24" iMac or my MacBook Pro laptop both running 10.6.2.
Each machine runs the same script to download and build the latest versions (Build.Distro.sh in svn). That script, downloads the latest and then next back, so for example, today it pulls 8.4.3 and 8.3.9. It then builds each version twice, once dynamic for the /Library/PostgreSQL8 path, and once for the static libraries used by the PGSQLKit in /opt/local. Once built, the output goes to a merge folder on a NAS device. Then comes the hard part.
One of the quirks of the build process is that every file in the resulting tree is single architecture, except one. That one is pgperl.so. That exception creates all kinds of hassles, since you can use lipo to merge a Universal binary to create a new universal binary, you have to first excise the distinct binary into a non-fat binary. We fought with the scripts to do this reliably for a month. It never worked right in the shell scripts, largely because of the way lipo writes to stdout and stderr. Ultimately, we ended up gutting that function out into an Automator Workflow / Applet that takes the file as a paramter and does all the work to thin the file for us. ( you will be able get the workflow from the Druware website shortly).
Finally there is the 'Merge' script that takes all of the files and reassembles them into the Universal builds. That is not checked into svn at the moment, but should be by the time the releases are published friday. After fighting with a nasty bash script to do this, we ended up using a modified version of the old AppleScript / Automator Workflow to do the merge.
At this point, the build process still has a few manual elements, but the worst parts are automated again. Hopefully, this means things smooth back out in timing releases with main tree releases.