Gotta say i love the old KDE3 tarball organization.
Once you have Qt and some other dependencies in place you build it up layer by layer.
present day KDE seems to have taken a page from Gnome, and now is a sprawling mess of tarballs.
The closest i have come to KDE3 on the GTK side is XFCE.
Similarly, while i understand that breaking things down to multiple tarballs have made developer life easier over at Xorg, building it requires compiling a pile of small tarballs.
> Similarly, while i understand that breaking things down to multiple tarballs have made developer life easier over at Xorg, building it requires compiling a pile of small tarballs.
I wonder if Xenocara works on anything other than OpenBSD...
I sympathize with your sentiment. Trying to maintain packages even for something as small as Xfce has been a nightmare (with all the Xfce-goodies, at least). I can't imagine what it would take to maintain so many packages needed for KDE and Xorg these days.
While "modular" sounds nice in theory, in practice you wind up wanting most of the modules anyway, so the modularity just becomes a pain in the ass. At the very least, some sort of "mega module(s)" would be nice: one could provide everything, one could perhaps provide a "20% of the code for 80% use cases" type of subset, perhaps there could be various customizations for special purpose applications, etc...
Once you have Qt and some other dependencies in place you build it up layer by layer.
present day KDE seems to have taken a page from Gnome, and now is a sprawling mess of tarballs.
The closest i have come to KDE3 on the GTK side is XFCE.
Similarly, while i understand that breaking things down to multiple tarballs have made developer life easier over at Xorg, building it requires compiling a pile of small tarballs.