In Tribblix Milestone 5, there's the dual element of increasing solidity and new development.
First, the new development: ZAP is a simple network package install utility. As in, really simple. Use it like so (as root):
zap install-overlay openexr
or
zap install TRIBpekwm
It should be obvious that it's nowhere near finished, but the necessary first step of having the command exist and the packages be available on the network has been achieved.
As part of that, the funky pkgs.zlib file on the iso that used to be lofi mounted for package installtion has gone. Instead, there's a directory with packages (in zap format) inside it. This is far simpler, and is also much quicker. With a little extra care in package construction, it's also smaller.
Next, a reversion. I've reverted the compiler and toolchain back to gcc3, as in earlier versions and matching OpenIndiana. Migrating to gcc4 is still a target (and is necessary for some newer software) but it has to be done right, and I'm not entirely happy with the gcc4 builds I've been testing. get the system compiler and toolchain wrong, and it's a mistake you have to live with for years.
And there's some polish. Most of this is covered by the change list. Many packages have been rebuilt, which can bring them up to date, optimize their space usage, or build them to my standards rather than importing them from OpenIndiana. Firefox is current, which is important. And there are little things, like including some themes for WindowMaker.
I've said before that there's no real roadmap or release schedule - this is, after all, largely a hobby project. And two months between milestones is rather longer than I would have liked. But to give you a flavour of what might be coming up - gcc4 done right, upgrades, LibreOffice, and working zones are all targets. (Of course, there's significant work in all those areas.)
2 comments:
Any chance of you describing what's _wrong_ with the gcc4 builds then, since a great many of us care a great deal?
Rich,
I think this is more of a problem with the way I'm building gcc4. Basically, anything in the application world I build with the current gcc3 works fine in terms of binary compatibility if I replace the gcc3 runtime with any gcc4 runtime. Where it all falls down is if I build applications with gcc4 (and I'm talking 4.6/4.7 or later, as some of the apps that need gcc4 need a pretty recent version) and then try and upgrade the compiler (or just modify the toolchain) later I start to hit compatibility issues.
To be clear, this isn't anything to do with the Illumos gcc4.4.4 compiler and the underlying Illumos binaries. They're fine, it's trying to get stable application builds that's giving me grief, and I just decided to punt now before too much depended on a bad gcc4.7 compiler.
Post a Comment