Since KDE 4.7 first alpha was released two weeks ago, we’ve slowly started work on KDE 4.7.x specfiles for OpenSolaris / OpenIndiana / Oracle Solaris 11 / Solaris 10 (what a terrible naming confusion — there’s the enterprise stuff from Sun, Solaris 10, which is old but semi-supported by us; there’s OpenSolaris which is dead under Oracle’s boot; there’s OpenIndiana which is an effort to retain Open-Source values in the Solaris OS world; there’s Oracle’s next version of Solaris, heavily weighed down with proprietaryness). I’ll just call it "KDE4 for Solaris" from now on, regardless of the specific flavor or trademark the software is packaged for.
The KDE 4.7.0 specfile repository was just started. It’s a clone of 4.6.0 up until last night, now with some minor updates. I don’t even think we’ve adjusted the KDE version number (from 4.6.3 to 4.6.80) yet. But the stuff will be forthcoming, eventually.
With this alpha release, a number of things have changed in the KDE stack, which is going to slow down at least initial Solaris packaging:
- Deprecating HAL and several other technologies lower in the stack (I’m not even sure which, but HAL is the biggie). The support burden for these technologies is being moved to the platforms that (still) use them. These platforms include Solaris, FreeBSD and Slackware Linux. Possibly more. This mostly affects libraries that KDE wraps around the lower-down technologies, like Solid. It’s an understandable decision, and I vaguely hope it ushers in a whole lot of test- and test-script writing in order to test various back ends (of which I guess we need at least four, now: Windows, MacOSX, HAL and udev).
- Changing the structure of the tarballs. These now match the split-up git repository structure. That’s pretty straight-forward to do (in terms of creating the tarballs from the repo) but introduces a bunch of changes in the packaging scripts. (Solaris uses RPM-style specfiles, which point at source tarballs and scriptlets for the actual build process) Where once we had kdebase-apps (one tarball) it’s now split up into bits. Konsole, for instance, is now its own tarball. So we’re forced to decide whether to (a) download konsole’s tarball during the build of our package kdebase-apps and munge the packaging build scriptlet to do it as well, or (b) create a separate package for Konsole and figure out how to transition from konsole-in-kdebase-apps to konsole-in-konsole packages?
The same issues affect Slackware, for instance. I think the KDE-FreeBSD team has already solved much of this for themselves (since it’s a packaging decision, not something to deal with upstream).
Anyway, all this isn’t intended to take anyone to task — just to explain why KDE4 Solaris packages for the KDE 4.7 alpha 1 will not show up quickly.
PS. gcc support in our specfiles is doing pretty well.