This release has 1650 binary packages available now. This includes binaries for KDE 3.1.4 and GNOME 2.4. The package manager has been improved and now includes a versatile system for handling variants. More documentation has been added featuring translations into Japanese, French, and Simpl. Chinese.
I wonder how difficult it would be for apple to write a similar binding scheme to quartz. If mono were to be integrated into XCode, I’d move to C# on Mac for all of my development needs!
We’re two…
There already is one, Coca# is shaping up nicely. See mono website for Wiki.
Yup Apple has a few of their engineerings working on cocoa# bindings.
Does this release fix the bug which prevents certain packages from being compiled when XCode 1.5 is installed?
That bug is with XCode 1.5, not fink. Apple has to resolve that one.
Has it been confirmed that the bug lies with XCode? If that is the case, I highly doubt Apple is going to do anything about it since fink seems to be the only thing that is broken when using XCode 1.5
Apple engineers know about it (a couple of Apple engineers are fink developers as well) and a fix is “in the works”. This bug affects other things as well (such as QT/Mac).
I read about that on their page, but didn’t pay much attention to it as hitherto I have had no problems with any package from fink stable. That’s what I periodically update from, are people encountering this problem when their repositories come from unstable in fink’s conf file?
newest, make-your-mouth-water desktop environments? A few weeks after someone releases an unstable source package x.0, x+1.0 is already released. Not to mention, the binary packages are even older. There is lots of great software for unix available through fink, but plan on staying with the standard MacOS X desktop. (I don’t plan on kompiling kde 3.2 on my iBook)
I’ve compiled Qt/Mac and have had no problems.
@MikeF: It mainly affects packages from unstable.
I appreciate Fink, but I ended up switching to DarwinPorts as my “main” ports system simply because the ports they have (about 1800 as of right now) seem to be kept up to date better. It’s really not as powerful system yet UI-wise, but they’re making pretty substantial progress in that direction, laying down the foundation for a very well-designed, modern system for handling both packages and ports.
There’s nothing that keeps people from having both systems installed, of course (although since they don’t know about one another, you’ll end up with a lot of unnecessary library duplication). DPorts is definitely worth keeping an eye on.