Slackware64-Current is made public…now what…

Pat has finally done it, the first official slackware-port in years, slackware64-current is public as of today. This is of course great news for kongoni… although it’s going to mean that kongoni x.13.0 is going to be a lot more work than I thought.

The problem is this: the 64-bit version of slackware official follows the proper LHA standards which makes sense since the majority of the work was done by Eric Hameleers from slamd64 fame. This is a good thing, but there was a reason why kongon64 used Bluewhite64 as it’s upstream.
The reason is that to do what Eric does requires the slackbuild scripts to be rather heavilly modified, while the bluewhite64 version basically just needs the ARCH variable to be set right.
For the most part – it meant we could maintain a single ports tree, with only minor architecture specific fields in the slackbuild scripts.

The first question of course is: what will bluewhite64 do ? I posted a forum question about this, since bluewhite64 is more than the port and also has a very wonderful live-dvd project, I could see a future for the project focusing on that.

Now the upside is that post-13.0 release we can safely expect the major slackbuild sites like slackbuild.org to try and support this platform… but what about until then ? More importantly – how do we as kongoni move forward ?
The obvious answer is that we ought to move kongoni64 to slackware64 when we go to x.13.0 – after all, that will be the upstream maintained most closely to 32-bit and it is more standards compliant.
This does mean some work though, we will need to investigate the ports -many of them will need to be significantly hacked – and the bigger one… this may mean we need to, like slackware maintain two seperate trees, and can no longer get away with a single one that installs on either platform.

Not an impossible task – just double the work.
Now a lot of the work in there will be made redundant by slackware 13 anyway as KDE4 is now official and so is it’s dependencies so I have no intention of maintaining these post slackware 13 release. I’ll focus on our customizations.
Or does it…
Well… I know 32-bit slackbuilds won’t build on 64-bit slackware – but perhaps they will build the other way around, after all – the ports tree only kicks in for add-ons. So if we write them right… we may be able to build kongoni’s x.13.0 ports tree in such a way that our slackbuilds build correct regardless of platform, by following the structures in the 64-bit scripts.
At this stage, I’m not going to worry too much about it – just keep an eye on it, I suspect slackware13 official is a still a while away.
What is clear to me now is that the degree of change means that doing a kongoni 1.13.0 is out of the question- we will just about have 1.12.2 out of the door in a month or two. There is no way we can incorporate this level of change (good change) inside our stabilization cycle.
So the first likely 13.0 based kongoni will probably be 2.13.0 – and we can expect to start working on it very shortly after 1.12.2 is officially released.

I guess the pressure is on to get Nietsche out of the door as soon as possible eh. We got a nice big buglist to sort out before then though – so let’s get to it guys.

UPDATE: A look at the 32-bit sources had an interesting result- the slackbuilds there seem to be build according to the same standard now coming to 64-bit… so that would suggest we could still do a single ports-tree, would be good.