This week I've spent a few late nights working on the OpenSolaris packaging of KDE 4.3.0 -- since 4.3.1 is out, it's just about time, don't you think? FreeBSD has the good stuff already.
New development repositories: we have been using Mercurial for a while for maintaining the specfile repositories that drive the packaging of KDE4 on OpenSolaris, which -- like any DVCS -- makes branching and merging and opening up development a breeze. That also means some unrestricted growth in the number of repositories and sometimes feature creep on individual repo's, so we've stopped for a moment to consider what's what. There are now five repositories, of which one is legacy, two deprecated for being too confused (but kept for a bit just in case someone is using them), and two repositories that are in current use.
The KDE 4.3.0 repository has specfiles for KDE 4.3.0 (this should not be a surprise) and the dependencies that we have built. Those include Qt 4.5.2, BOOST, Apache stdcxx and lots more. This repository is considered stable and should not change any more. The 4.3.1 repo is not stable, and is under construction.
Things that will go into the 4.3.1 repo are an update of poppler to 0.10.7 (current version) and of course updating KDE to 4.3.1; this also means adding the new KDEpim-runtime module to the set of packages. We don't package it for 4.3.0 and that doesn't seem to hurt KMail. We hope to improve collaboration with Belenix by stealing all of their updates to the dependency tree, while we're at it.
[[ And there was a Qt security announcement on September 1st -- that one is in both repositories and applies to the packages that are available as well. ]]
New IPS package depot: in the past three months or so we have accumulated a crufty set of packages on various IPS servers; these have been knocked down and a fresh set of IPS packages is available from the publisher http://pkg.bionicmutton.org:10000/ (also supports port 8080, by popular request).
These packages are the ones built from the 4.3.0 repository using Sun Studio Express on OpenSolaris 2009.6 and are supposed to "just work." As usual, people with the initials MS will find out that they don't -- honestly Michael, what do you do to those poor install images.
Tools usage: the KDE4 packages are still not built using Source Juicer. This is easy enough to explain: because it's a family of 122 packages which share settings and common files, it's difficult to merge into Source Juicer effectively. We have tried, and SJ does drive us to do some simplification and a reduction in the number of files used for the build, but we are not there yet.
Instead, packages are built on a stock amd64 (an X2 4850e w/ 6GB RAM under my desk) OpenSolaris 2009.6 install, then tarballed using the tools from the IPS best practices wiki, archivepkgs.py in particular. These are copied to the actual server which then needs to be restarted every time we import new packages -- wanting to avoid the restart is what led to our wild growth of IPS servers.
One tool I'm missing (lazyweb wishlist warning) is one that cleans up the on-disk pkg depot; I'd like to be able to strip out all but the most recent version of every package from a depot. I have an inkling of how this would work (determine what's "latest", flag all the files it uses; later walk the filesystem tree and remove all non-flagged files), but I don't feel like going the destructive route myself right now.
There's a problem in pkg(1) with large file uploads, so publishing the packages directly to the server is infeasible; that's something that we need to fix with a nice workflow and one appointed person to kick the depot server when needed. This will happen once we have KDE 4.3.1 packages built and somewhat tested.
Stability: There are some known crashes; Dolphin has some threading issues and KMail crashes on exit, for instance, but the overall impression I get from running KDE 4.3.0 as my desktop on OSOL is pretty good. Even with an underpowered X1200 onboard video. With a proper video card (e.g. the GF9600 512MB on my laptop) things are much nicer.
Feedback: Please use the kde-discuss forum/mailing list or file bugs in the regular KDE bug tracking system and set the Operating System to Solaris in your report. We appreciate bug reports (if you can, check that they are Solaris-specific by comparing with, say, FreeBSD behaviour) and appreciate patches even more. Remember, the specfiles are open and everything can be built from source by following the instructions on the KDE TechBase page on OpenSolaris (and that's a wiki, so if the instructions are not clear, you can help improve them!).