[kde-solaris] KDE 3.4.3 Patches and Upgrades
steleman at nyc.rr.com
Sun Apr 16 19:50:22 CEST 2006
On Sunday 16 April 2006 12:42, Derek Konigsberg wrote:
> That all sounds very disconcerting, as a project like KDE should be
> striving to have a clean and *portable* code base. (Whenever I
> have to "beat code into submission" to make it compile on Solaris,
> half the time I'm running into issues that only exist due to gcc's
> lax-ness anyways.)
> As much as it might sound like an undesirable fork, I'd definitely
> be interested in having a Solaris compatable source tree that was
> kept in sync with the "we only care about Linux" tree. (along with
> a source distribution that anyone could download/compile/package to
> their needs)
> I'd even volunteer to host a repository for such a project, if
> that'll make things easier. (I have a Solaris-based co-lo server
> that I'm always looking for more things to do with.)
Thank you for the offer.
I am in the process of setting up a SVN repository for KDE Solaris
with help from a KDE Solaris friend. It's not ready yet, mostly
because i've been so busy fixing these bugs, and i wanted to create
this repository with a more complete set of bug fixes, but now i
should be able to spend more time on it.
Bring up the issue of code portability, and you will be instantly
dealing with three troll topics:
1. "Solaris sucks"
2. "Sun Studio Is Buggy -- GCC Is Always Right"
3. "This code is portable on my box"
Needless to say, i am not really interested in participating in any of
these three discussion topics. :-)
The fundamental problem i see with setting up these "Friends of KDE
Solaris" repositories is that they make everyone realize that they
are a secondary alternative to the real approach. And at this point,
everyone is right in asking the question "why is KDE not interested
in at least keeping at least some control over these forks ?" I am
not convinced that having several forks of KDE floating around the
world is maintainable, or desirable, in the long-term.
In a theoretical world, there should not be a need for operating
system specific forks. In the real world, anyone who has ever been
involved in writing complex systems, required to work correctly on
more than one flavor of UNIX, knows that this theoretical ideal is
simply not possible. At this point, one is faced with two choices:
- keep everything in one trunk, and #ifdef every other 10 lines of
code. if you want to see how maintainable that codebase can become,
take a look at X.
- have one "main" trunk, and subordinate forks for specific UNIX
flavors. this keeps trunk clean, keeps the subordinate forks cleaner
as well, and does not pollute the main trunk with flavor-specific
changes. and it keeps Solaris specific changes away from those who
are allergic to Solaris. :-)
It is also equally true that Sun should have been, and should be, more
involved in helping KDE Solaris. It *is* in their own interest to do
so. Well, they aren't. They keep trying to push that JDS product.
Sorry guys, that ain't flying. They've been at it for 5 years, and i
still can't think of a single reason why anyone would ever consider
And this is *not* a GNOME jab. I have nothing against GNOME, and i'm
not interested in getting involved in some stupid "GNOME vs. KDE"
flamewar. Just take a look at any real distro of GNOME, then take a
look at JDS, and then reach your own conclusions.
Stefan Teleman 'Nobody Expects the Spanish Inquisition'
steleman at nyc.rr.com -Monty Python
More information about the kde-solaris