Gan Starling <oinkfreebiker@att.net> wrote:

>I figure this must surely be a broken element of NetBSD's 
>package of KDE since there is no listing of it in the 
>MARC archive of many, many mailing lists. No listing 
>except for my own. Nobody in Linux-land would put up with 
>anything this broken, I don't think. KDE would certainly 
>have a very bad rep if nobody could email a doc composed 
>with its own editor.

You're making a couple of bad assumptions here.

The first is that the NetBSD package system makes a lot more changes
to a package's source code than it does.  For the most part, the
package system only changes the build and install framework a little,
giving the build process the right flags to find the files from
other packages it depends on, and occasionally rearranging a package's
install locations to conform to NetBSD's standard hierarchy (bins in
${PREFIX}/bin, docs in ${PREFIX}/share/doc, etc...)  That is why the
majority of the patches in pkgsrc are to Makefiles or configure
scripts.

On the occasions when the package system does patch an actual source
file, it is usually because the source does not properly natively
support NetBSD.

As an example of this, the three patches to net/kdenetwork2 (which
is the package where kmail is located) are:

patch-aa: gives kppp the proper list of devices for NetBSD
patch-ab: fixes configure to find -lPTL instead of -lpthread on NetBSD
patch-ac: puts the USE_THREADS (from patch-ab) in the proper place in
  knode/Makefile.in

Note that nothing here actually changes any of the code in (e.g.) kmail.

This brings us to your second bad assumption:  that, just because
something compiles and appears to run in Linux-land, it doesn't have
any bugs.  Unfortunately, it's become very apparent that many
open-source developers have moved almost exclusively to developing on
Linux/i386, with at most a cursory "make sure it still compiles" pass
on other platforms, if even that.  Oftentimes, with complex programs,
this means that bugs can be covered up by quirks of how certain system
processes function on Linux.  When these bugs do uncover themselves
on other platforms, those platforms are blamed instead of recognizing
the invalid assumptions and bugs in the code itself.

A significant recent example of this is the failure of XFree 4 to
properly restore the VGA palette registers upon exit - because the
Linux virtual console code also restored the palette upon switching
modes, the bug in XFree went unnoticed, and was then, upon discovery,
blamed on the OSes it was found on, including NetBSD.  It took quite
a while until the actual bug was fixed, simply because the Linux
people couldn't reproduce the buggy behavior, thus the code "couldn't"
be buggy.

That is not to say that NetBSD is 100% bug-free - I don't think any
significant piece of code in the world can make that claim, as there
are too many assumptions that go into it.  But what I can say is not
to jump too quickly on NetBSD as the "broken" party just because the
bug doesn't make itself visible on Linux.

jdarrow

-- 
John Darrow - Senior Technical Specialist               Office: 630/752-5201
Computing Services, Wheaton College, Wheaton, IL 60187  Fax:    630/752-5968
Pager via email: 6303160707@alphapage.airtouch.com      Pager:  630/316-0707
Email:     John.P.Darrow@wheaton.edu