[KDE/Mac] Hi (from Kolab Client "Team", part of)

[Mike McQuaid]

2010/8/24 Bernhard Reiter <bernhard at intevation.de>:
>> I guess I just mean the patches that are specifically listed in the
>> Macports/Fink build files and can be easily obtained from there. For
>> example:
>> http://trac.macports.org/browser/trunk/dports/kde/kdelibs4/Portfile and
>> http://trac.macports.org/browser/trunk/dports/kde/kdelibs4/files
>
> This has only a few patches.
> What about starting a list of patches that should go upstream?
> Maybe in a wiki? Techbase?

These should definitely go upstream in some form:
http://trac.macports.org/browser/trunk/dports/kde/kdelibs4/files/add-bundles-to-path.patch
http://trac.macports.org/browser/trunk/dports/kde/kdelibs4/files/fix-bundle-icons.patch
http://trac.macports.org/browser/trunk/dports/kde/kdelibs4/files/patch-cmake-modules-FindKDE4-Internal.cmake.diff
http://trac.macports.org/browser/trunk/dports/kde/kdelibs4/files/workaround-kdeinit4-crash.patch

The other patches shouldn't go upstream as-is but should be added as
options to disable unwanted components on OSX.

> Given limited resources, I believe it is better to deliver something
> coming out of a mid term viable infrastructure and trying Mac people a bit
> to use it. As opposed trying to create a slick installer and then fail to
> follow through with updates over the next years.

Fair enough. I guess I see the Macports solution as being one we
already have and I want to try and improve on it. It depends if you
are targeting system administrators, unix geeks or novice end-users.
Until we have a native OSX method, we won't attract the latter.

-- 
Cheers,
Mike McQuaid
http://mikemcquaid.com/