On 13/03/2014, at 12:46 AM, Kevin Krammer wrote: > On Monday, 2014-03-10, 17:06:53, Ian Wadham wrote: >> On 09/03/2014, at 8:23 PM, Kevin Krammer wrote: >>> Hi Ian, >>> >>> On Sunday, 2014-03-09, 17:33:12, Ian Wadham wrote: >>>> Hi Kevin and Frank, > >>>> I think they probably are non-overlapping sets. There *is* a KDE Mac >>>> mailing list, but I receive only a few posts per year from it, as >>>> compared >>>> with several a day from Macports. >>> >>> Ah, interesting. >>> This makes it very different from all other platforms (various Linux >>> distributions, BSD, Windows, mobile platforms), where some of the >>> packagers >>> are also KDE developers. >> >> Macports grew out of something Apple did in the early days, mainly directed >> at getting any kind of free open-source software onto Apple Mac. There are >> also Fink and Homebrew doing similar jobs. >> >> A lot of the emphasis is on GNU utilities and languages such as Perl, TCL >> and Python, plus some Science packages and Fortran, used by real scientists, >> free database packages (mysql, mariadb, sqlite, etc.). >> >> The Macports have fantastic Unix/BSD and sysadmin skills, but not much >> knowledge of KDE. The KDE porting team does a good job and are currently >> at KDE 4.12.2, but they make not much attempt to adapt or convert KDE to run >> smoothly in the Apple OS X environment. One guy goes a bit deeper, with >> KMyMoney4, and is in touch with the developers, I think. I help him too, >> when I can. Both of us rely on KMM4 to run our finances … ;-) > > I see, that makes it indeed very different from packaging efforts on any > other > platform.
Well yes. I think the KDE community is very lucky to have such helpers, but I guess you cannot count on them being present on every platform … >>>>> That might of course be true, but also a bit uncommon. Packaging efforts >>>>> for all other platforms is at least to some extend handled by people who >>>>> are either users of the packaged software or KDE developers using the >>>>> respective platform. >>>> >>>> Part of the problem may be that, until recently, it has been difficult >>>> for >>>> a KDE developer to just buy a MacBook Pro and set up a dual-boot or >>>> virtualised Linux system on it. But now it is quite easy … :-) I aim to >>>> have a go, once I have Palapeli for KDE 4.13 put to bed. >>> >>> The main part of the problem, i.e. Apple at least officially requring >>> special hardware, still remains. >>> I am not sure it is feasible to assume anyone would buy a second computer >>> just to satisfy some hardware vendor's lock-in phantasies. >> >> I think your prejudices are showing, Kevin … :-) > > That might very well be. > I actually know people who have a so called Hackintosh, but I've never > figured > out how they actually get OSX. OS X is bundled in and stored in the hardware when you buy it and has a well thought out mix of default settings. It remains for you to set up user and admin accounts, which the Apple Shop help you to do. For updating (when you feel like it, no pestering) you run AppleMenu-> Software Update. It tells you what new items are available and what the significance of each new version is, and then you can choose which ones to install. Major upgrades, such as Lion 10.7 to Mavericks 4.9 are offered by email, with links to websites describing the features. You can obtain an upgrade from a website when and if you want it. It is not unlike working with OpenSuSE. > My information, and it seems to be confirmed by other people in this thread, > was that Apple did not sell OSX licenses separately, only bundled with their > hardware. > > Another piece of information that might be outdated is that Apple's license > terms, at least in some jurisdictions, do not allow to run OSX in a > virtualized environment. > > Which made OSX almost impossible to use in continuous integration and removes > the only viable option for quick test build and test runs for the average > developer. > > Again my impression from other responses is that this is still true, but > these > responders might like me also not be up to date on the whole situation. > >> Actually Apple Mac >> hardware is bog-standard Intel underneath and OS X is BSD UNIX >> underneath. > > Right, but that is the "buys special hardware" situation I was referring to > before. > >>> Do you know if the Mac packaging group is just building the software or if >>> they also run the automated tests? >> >> I don't know for sure, but I think they just build, sometimes patching to >> overcome incompatibility problems and build failures. > > I see. > >>> My assumption until this thread was that OSX as a target platform was >>> handled similar to how all other were handled, i.e. a group of people >>> with deeper understanding of the platform's peculiarities would build the >>> software, fix eventual problems and upstream those fixes. Doing the >>> latter through persons within the group who are KDE developers. >>> >>> My updated understanding is that the group packaging KDE software for OSX >>> does not have any members who are KDE developers, >> >> I am not certain of that, but it is probably so. > > right, seems we need a different approach for this platform then. relying on > a > domain expoert community doesn't seem to be an available option in this case. No, not really, but expert help would be welcome, I am sure, and would help motivate and retain the guys who handle KDE. And KDE might even gain a developer that way … >>>> Another source of problems is the excessive list of dependencies >>>> in KDE (see attached). >>> >>> A lot of that seems to be purely build dependencies, not something an end >>> user would be affected by. >> >> Well I am. You'd better believe how long it takes to go through all >> that Nepomuk stuff on a limited bandwidth broadband connection, >> let alone compile it, if any of it has to be compiled from source. And >> those dependencies have caused lots of problems in Macports in the >> past and they used to cause me endless problems when I worked >> on a Linux system. > > Yes, sorry, probably bad phrasing on my part. You are affected because you > are > a developer, I meant that build dependencies are of no concern to end users. The end users are also affected - especially in the days when all that stuff had to be downloaded and compiled. Nowadays the most common ports are packaged as binaries. My first "sudo port install kdegames4" command, in 2011, ran for about 24 hours, with all 4 cores flat out. I could have kept my coffee warm on my machine. Quite hair-raising really … but nowadays kdelibs4, qt4-mac and other major dependencies of KDE Games are packaged as binaries. >>> And some of the dependencies look "wrong", e.g. the X11 ones. >> >> They might be, but Apple is rather ambivalent about X11. It's an >> ongoing issue. Some packages require X11 on Apple, such as >> Gimp and Inkscape. It looks as though libsdl does in this case: >> and strigi depends on ffmpeg which depends on libsdl. > > Hmm, I would have expected that libSDL has a native Mac port. > > Anyway, my point was that X11 should not be a dependency on a non-X11 > platform, just like it is not on Windows. > Maybe some build system files do not yet distinguish between "main" and any > other alternative than "Windows", i.e. trying to run a Mac build like a Linux > or BSD build. I think it is because of what Macports calls "variants", which are global. Maybe there are some non-KDE packages which require the libsdl library and they require the +x11 variant, so then everybody gets it. Just as KGoldrunner gets Nepomuk, et al. … ;-) Gimp is certainly a package that requires libsdl and also X11, in the Apple version. I see also, on Macports package info for libsdl, that the default variant for libsdl is +x11, so that is why a KDE app is getting it (but indirectly via Nepomuk and Strigi, so libsdl might never actually get used - unless an app uses [invokes] Nepomuk directly). Cheers, Ian W. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
