[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-mac
Subject:    Re: [KDE/Mac] Developing KDE on Mac
From:       Mike McQuaid <mike () mikemcquaid ! com>
Date:       2010-08-13 12:46:51
Message-ID: 99A86582-64CB-43B0-82F1-5218AB418DE5 () mikemcquaid ! com
[Download RAW message or body]


On 13 Aug 2010, at 12:46, Sjors Gielen wrote:

> I've been thinking about this and while it seems a good idea at start, I nowadays \
> don't think it's the way to go. Of course it's true that the packages should be \
> compilable and should work on first install, but when you consider the amount of \
> work needed for dependencies, keeping everything up to date and all, installing a \
> package manager like Fink or MacPorts is really *way* easier than compiling an \
> installing KDE from source yourself. So much for the easiness factor, which is for \
> most of us not the most important factor. 
> The second one is the dependencies I already named. Point is: when KDE needs dbus, \
> who installs dbus? It's not shipped with the operating system. If the user has to \
> compile and install that himself *too*, along with the ± hundred other dependencies \
> of KDE, it makes the system dirtier with non-updated deps, and that could \
> eventually also have negative effects on the quality of the system. (I'm not even \
> talking, here, about dependencies which are by default uninstallable on Mac. Most \
> projects care about that - but I've seen projects reject patches because they \
> didn't want to have the additional maintaining burden of supporting another \
> operating system.) 
> All in all I definitely think we should come together and improve the situation of \
> "vanilla" KDE on Mac, but I think we should strongly advise against compiling and \
> installing yourself, unless you really know what you're doing (for example, a KDE \
> developer who has everything in Fink/MacPorts and simply wants to build kdewhatever \
> for himself). We should then, in my opinion, have a policy of sharing patches \
> between Fink and MacPorts and also submitting them upstream if that makes sense. \
> First thing to do is update the horribly outdated set of pages at \
> http://mac.kde.org/, by the way.

When doesn't it make sense to share patches upstream? If Fink and Macports are \
sharing them and you don't recommend people install from source these patches should \
all be upstream.

I agree with Fink/Macports being better for most developers. Most people don't \
install all their dependencies from scratch on Linux either but people do install Qt \
and KDE and, currently, this isn't possible on OSX without patches which are in Fink \
or Macports. This is a bad situation. I don't think the solution is sharing patches, \
I think it is for Fink/Macports to try and be a bit more responsible open-source \
citizens: actually push patches back upstream. Yes, it takes effort but that's kind \
of the point of open-source.

I'm trying hard to push the launchd patches upstream to D-Bus but it's a huge pain \
and it's taking time. However, though, it will be worth it as it means we get closer \
to the situation of sensible binary distribution. More on that later.

> One thing that has been crossing my mind since aKademy is a KDE on Mac installer. \
> The Windows dudes have done this and it's been working out great - but they don't \
> have a package manager and we do. I've been thinking about creating an installer \
> that, after some basic system checks and asking the user what he wants, installs \
> Fink or MacPorts, configures that, then proceeds to tell the package manager to \
> install KDE. It could become a KDE-oriented "front-end" to Fink and MacPorts, also \
> alerting the user of updates now and then.

This is exactly what I'm trying to avoid. On Windows their "installer" is a package \
manager that they wrote from scratch. If we want KDE on Mac (or indeed KDE on \
Windows, quite frankly) to ever catch on with non-technical and non-Linux users who \
have to use Mac/Windows on occasion, then we need to start bundling our software the \
way people expect it to be distributed.

Fink/Macports/Homebrew are great tools. However, no non-developers I know that use a \
Mac use them. Hell, most developers on OSX who aren't doing open-source development \
don't even use them.

What our end-goal should be is a nice DMG with a PKG or droppable .app file with \
autoupdate support and all the trimmings people expect. On Windows, in my opinion, it \
should be a MSI or NSIS installer that doesn't force the user to worry about \
dependencies.

I think a reasonable intermediate step would be to have a DMG which installed the \
basic dependencies for KDE applications (e.g. D-Bus, Qt, KDELibs, KDESupport) and \
then .app bundles for individual applications.

I did a talk on using CPack to do this at Akademy the year before last. I really \
think this is something that we should seek to do a) as a group/team and b) properly \
rather than just the easiest way possible.

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

_______________________________________________
kde-mac@kde.org
List Information: https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac Information: http://techbase.kde.org/index.php?title=Projects/KDE_on_Mac_OS_X


[prev in list] [next in list] [prev in thread] [next in thread]