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

List:       kde-devel
Subject:    Re: What to test for 4.13?
From:       Kevin Krammer <krammer () kde ! org>
Date:       2014-03-14 8:46:50
Message-ID: 1800319.pXNeFnXc7c () persephone
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday, 2014-03-14, 12:07:47, Ian Wadham wrote:
> 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,

> >>> 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.

Right. I understand how people get OSX on Apple's special hardware, it is 
preinstalled. I was wondering how people running it on generic hardware get 
it.
There is no point in buying that Apple hardware and then not using it. And it 
doesn't help at all with the problem of having to buy that special hardware in 
the first place.

The only interesting option is how to run OSX without having to buy new and 
additional hardware, isn't it?

> > 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 …

From your reponse to John's mail, i.e. macports people totally ignoring your 
attempt of cooperation, that sounds highly optimistic.

> >>> 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.

Well, a Linux end user that runs Gentoo will have to deal with build 
dependenies as well. But that is their choice.

I hadn't imagined that a packaging effort for OSX would do that as well. My 
assmption was that especially on OSX one wouldn't want end users to have to 
deal with that.

My obviously uneducated guess would have been that it would be more similar to 
Windows, i.e. having a single app store like installer that would download and 
install everything needed by the chosen applications.

Maybe that is something the OSX packaging community should have a look into.

> 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.

Seems they are on the right path then.

> >>> 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. … ;-)

That is a serious packaging problem then.

Or rather there seems to be a huge gap between the target audience of the mac 
packaing effort and the people wanting to use it.
Has anyone pointed that out to them?

And is there no packaing community targetting the usual OSX users?

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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