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 ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Fink-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-users
