The KDE4/D-Bus stuff is starting to settle down, and it looks like trunk is starting to regularly build again. It'll be worth seeing if it's stabilized pretty soon.
Also, Peter O'Gorman, Torrey Lyons, and I have been working on getting X.org 7.1 building. Torrey committed a ton of fixes in the monolithic (6.9) tree to fix building with the GL and other changes that happened between 6.8 and 6.9. Now we're trying to get all of that into the 7.x (modular) tree. I've got everything up to the X server packaged in my experimental tree and I've been playing with seeing how things do when built against it. Peter just got XDarwin.app building enough to start up, although it doesn't work yet. Hopefully things will start working soon.
I'm taking this opportunity to work towards making X.org 7.x the "official" X11 of Fink. I've been doing some tests with mixed binaries (some libs linked against /usr/X11R6 and some against /sw/X11) with good results. Eventually, the goal is to transition all X11-using packages in Fink to link against the /sw/X11 tree, and let end-users have whatever X they want in /usr/X11R6 for their runtime. Because of the client-server nature of X11, everything should be able to coexist pretty peacefully. (Stuff linked against /sw/X11 will still run with apple's X11.app and so on.)
In addition, there have been a few general updates released to 10.3, 10.4-transitional, and 10.4:
-
KDE 3.5.3 and Qt: but then, you already knew that
-
kdelibs, kdebase, kdenetwork: security updates
-
KOffice: updated to 1.5.1
-
poppler1 and poppler-qt3: updated to 0.5.3
-
PostgreSQL: but then, you already knew that 🙂
-
Rose: Rose::DateTime 0.53, Rose::DB::Object 0.731, Rose::DB 0.71
-
wv2: security patch
Thanks for your work.
One question – why use /sw/X11 if it is able to put new X11 in the same location as all other programs – /sw?
I’m asking because after debian switched to Xorg7 – there is no /usr/X11R6 direcory, because all libs and progs from Xorg packages gets installed into FHS-compilant paths
Because if we did that we’d have to change all of the packages that build against X11 at once.
Debian gives you only binaries, so stuff won’t change if it was linked against the old /usr/X11R6 stuff.
Fink does source builds, so you’d end up with the same package “foo-1.0-1” having different runtime dependencies depending on whether you happened to have fink’s x.org installed or not.
This lets us isolate X11 and only link it explicitly if we know we’re asking for it. New packages will slowly change to use the new X11, and old stuff will continue to build against the system X11 until the maintainer has time to update his package to support x.org’s libraries.
All of this sounds great.
Koffice 1.5.1 succesfully installed in Fink, works great. Nice !
Great job !!
Suggestions for KDE Qt/Mac
For KDE what would be great
Qt 4 in /Library/Qt.framework less all the useless stuff to get a not too heavy library.
KDE libs in /Library/KDE.framework without the useless things, for same to get a not much heavy library.
Postgre SQL in /Library/PostgreSQL.framework
~/.kde in ~/Application support/KDE
KDE base applications bundled in /Applications/KDE or anywhere else
Koffice applications bundled in /Applications/Koffice (Kword.app, Kspread.app, Karbon14.app, Kexi.app, Krita.App ……) or anywhere else
like this all is well organised, coherent with the system and easy to manage, gotten rid of all the useless stuff for a normal office end-user.
Also the frameworks can be used by other softwares that could need them without to have them hundred times on the hard drive and as a result waste space.
It is what the maintener of Aqua Scribus did, I think he is on the way.
What do you think ?
I’d like to do that eventually, Jack, but hoo boy that will be a lot of work. KDE still has a lot of expectations about where things belong on the filesystem as far as resources and stuff; step one is to just get things working. 🙂
~/.kde already goes to ~/Library/Preferences/KDE although I suppose maybe it should be in Application Support instead. Not sure how KDE will like spaces in the directory name, but hey, that would be a bug that needs fixing. 😉