
The announcement of KDE4.1 in slackware-current was the push I needed to go back to my old friend. But, woe is me, slackware does not support 64bit platforms natively and 32bit software on a 64bit CPU is slow.
Even if that software is slackware :p
So what to do ? Well there are two major unofficial slackware ports for 64bit platforms. SlamD64 and BlueWhite. I chose Slam64 primarily because it’s not a pure 64bit OS and has 32bit compatibility libs included. A lot of work by one very cool student named Fred. Now just one major dev may be scary with some distro’s but it didn’t bother me too much about slamd64, after all slackware itself only has one major dev and it’s the oldest surviving distro in the world ! And after all these years, still cool.
But there is one catch, Fred has not had time to keep slackware-current up to date so right now slamd64 doesn’t have KDE4.1 available, since the testing tree doesn’t exist.
I decided to do something about it. Now I don’t have that much time either so I sure wasn’t going to port the entire slackware-current to the slamd64 structure – but I did want KDE4.1
I decided to build it. I am about halfway now, with a really proper QT4 package finally compiled. It’s going to take a few days still as every package needs to be compiled and tested many, many times as I hack at the slackbuilds.
I used the slackware current sources to base my packages on, but I have made some crucial decisions.
1) Since I didn’t want to port the whole slackware-current alone – or live without KDE for that many weeks – my packages are not only being crossported to X64, but also backported to slamd12.1. Only where a library absolutely has to be upgraded am I building anything outside the testing/kde tree. So far the only libraries that are upgraded beyond pure slamd64 as it comes from the disks is fontconfig and freetype – needed for nice antialiassing in the new QT.
2) My packages do not include a QT3 backward compatibility lib as a separate package. I tried a dosen times and the changes Pat made in the compat package just isn’t compatible with the slamd64 way of doing things, it keeps breaking all your libs meaning lots of reinstalls. Instead, I enabled qt3support in QT4 which is mostly SOURCE backward compatible. This means it will take some more work than usual to get KDE3 packages to play nice because if they are compiled against stock QT3 it isn’t binary compatible. Sorry folks, nothing I can do about that – I spent hours trying. If somebody else feels like giving it a go once the packages are out, I’ll be happy to include it. I’m going to compile my kdelibs3 against the backward compatible QT4 though, for what it helps. To make a package work, you will need a dedicated KDE3 machine to build it on (as with Pat’s packages) but you will need to install my QT4 package on it – this means it has to be a 64bit machine, running slamd64 -then you will have to change the QTDIR path to make sure you link against my QT in your SlackBuild script.
3) This is not an official part of slamd64 and I have no expectations of support from Fred, he works hard enough already, it’s something I am doing because I want it badly, and I’ll be sharing the results because that way I may save some other people from having to either forgo KDE4.1 or change distros (equal tragedies methinks).
Once all the packages are built, I’ll create a proper slapt-get friendly repo and put it up on this site for others to use. I am calling my project slamDUNK. Which stands for slamd64-UNoficial-K (the K of course for KDE).
Thanks to Fred personally for his advice right at the start which got all this going in the first place.
The packages are not dependency tracked (sheez, I only have so much hobby time) but I will add a metapackage which will have slapt-get dependencies on all the others in the right order so that you can install KDE4.1 as easily as possible from slamDUNK.
I also intend to add a few other interesting package I build to the repo over time, though they will be in an extras directory as this repo will remain primarily focussed on providing KDE packages. I will also share my modified SlackBuild scripts but beware – they are UGLY right now (I am pushing for time here – I’ll clean them up for round 2) – hopefully that will help others who wish to expand it.
And yes, this is going to be an ongoing project for some time – at least until KDE4.X is part of a mainstream slackware release with an official slamd64 port. Even then I will seriously consider doing weekly packages from trunk or something for bleeding-edge people if there’s enough demand.
That’s the great thing about free software. Sometimes you do it because you should. Sometimes you do it because it’s fun and challenging – and sometimes… it’s both – and you have a great time with not nearly enough sleep.
I have been using end-user aimed desktop GNU/linux distro’s for so long that without me realizing it I had begun to get bored with GNU/Linux… things always just working is convenient and was important when I ran a company – but now my computer at home is mostly a place to play and learn again, and it took going back to slackware to remind me how much I actually like fiddling, making hard things work and figuring out tough challenges.
Using KDE is easy – packaging it is challenging, but some of us enjoy that challenge. The lovely thing about GNU/Linux is- whichever you are, we have a distro for you.
I’ll keep everyone posted on the progress, I am hoping to have a working system in another day or two, then just some testing and if all goes well – the repo should be up by the weekend.