[KDE/Mac] kde4 on Tiger using macports

[Orville Bennett]

On Jan 8, 2009, at 6:00 AM, Jonas Bähr wrote:

> Am 08.01.2009 um 02:45 schrieb Orville Bennett:
>> On Jan 7, 2009, at 6:07 PM, Jonas Bähr wrote:
>>>>> SNIP
>>>> I'm proud to annouce that I am 10 steps ahead of you! ;-)
>>>
>>> Well, in fact I'd prefer to cooperate rather then compete with  
>>> you...
>>
>> Likewise, I was just poking a bit of fun. Note the sly usage of the
>> winky face.
>
> No, problem, I didn't take it seriously... But since you uploaded  
> dbus-legacy four days ago it would have been nice to inform this  
> list about the progress.

You're right. I decided to wait until I had everything sorted.  
Should've just let you all know though.

>
>
>>>> see dbus-legacy port. it conflicts with normal dbus so deactivate
>>>> that
>>>> first.
>>>
>>> The problem with this approach is that you can either install kde4,
>>> *or* any other app needing dbus. (appart from the fact that
>>
>> No, not really. What set's this port apart from the normal dbus port
>> is that x11 support isn't built in. Well, that and Benjamin's launchd
>> patch. And the older version of dbus... well you get the idea.
>>
>> If X11 support _is_ built then dbus will do it's normal x11-y stuff
>> just fine. I can include the no_x11 variant in the port (and make it
>> the default as, if we're building kde on os x we don't want X pulled
>> in inadvertently). I just don't see many people who use KDE also
>> wanting X11 stuff.
>
> one never know. people using kde-stuff on a mac, may also use gnome  
> stuff there too.

I have no sympathy for these people :-)

>
>
>> I'll wait for the trac tickets to prove me wrong though :-)
>>>
>>> debus-1.2.4, suffers from the security issue CVE-2008-4311. I don't
>>> consider it sensitive for most setups though).
>>
>> Nor I, but I rarely pay attention to such things. :-)
>
> as the maintainer of this port, you should. Or at lest inform your  
> users.
>
>> There is an updated 1.2.4 release which probably addresses this but,
>> honestly I just didn't want to deal with this. I'll check on it this
>> weekend hopefully.
>>
>>>
>>>
>>>> I do need to port the kde portfiles over to it, but i'm waiting  
>>>> till
>>>> the weekend to do all that (just moved, yada, yada).
>>>> BUT if someone wants to volunteer...
>>>
>>> Due to the conflict with the default dbus package I'll stick with my
>>> shell-script (for now). I'll try to put the patch in shape for the
>>> official dbus HEAD. If done right we can have a launchd enabled dbus
>>> per default in macports.
>> Which would be great.
>
> The latest patch (refactored by Colin Walters) applys nearly (only  
> one context change) and compiles nearly (just one forgotten ';'). It  
> seem to work here. So, it's quite easy to provide the launchd  
> variant in the official dbus port.
>
> It rests to patch the tools (dbus-launch, maybe others too) to use  
> launchd instead of x11 for autolaunching. This would make dbus  
> either x11 or launchd, but it would adress any open autolaunch  
> issues on a mac. AFAIK it uses x11 only to store the session bus  
> address, so there is no problem in moving over to launchd compleately.
>
> I attached the patch against HEAD, I'll look at the tools later.  
> Maybe you want to use it to drop dbus-legacy in favour of a +launchd  
> dbus... You have to load the dbus-session.plist into launchd to make  
> it work. I think it's the same with benjamins patch.
> <launchd-colin.patch>
>>> In the mean time dbus-legacy as dependency for kdelibs could be a
>>> workable solution. It also works around the x11 issue from https://trac.macports.org/ticket/16755
>>> #comment:36
>>> Only the installation procedure becomes a bit tricky.... installing
>>> qt4-mac (which pulls dbus), then deactivate dbus, then install  
>>> kdelibs
>>> (which pulls dbus-legacy)
>>>
>>> perhaps you could rename it to dbus-launchd, to make the purpose a  
>>> bit
>>> clearer...
>> I could, and initially that was exactly the name I was going to use.
>> On further thought I convinced myself that this sounded instead like
>> some extension that allows dbus to use launchd.
>> It's not, it's actually dbus, patched to use launchd.
>>
>>> KDE does not depend on a legacy version of dbus but to a
>>> version which can deal with launchd (which is unfortunately not the
>>> latest, for now)
>>
>> Right, but the version provided _is_ a legacy version. If dbus proper
>> gains the ability to use launchd then that port will simply replace
>> the dbus-legacy as the dependency.
>
> Also true. What about a +launchd variant, enabled by default  
> (likewise with +no_x11, it seems to be wider used then -x11)

In the normal dbus port launchd should just be built by default. It's  
not pulling in anything extra so a +launchd port would have little  
value. Variants, from my understanding, aren't meant to split ports  
up, but instead to manage dependencies.
The dbus-legacy port only exists for launchd support so a variant  
would be pointless here.

>
>
>>> bye,
>>> Jonas
>>
>> Night.
>>
>> _______________________________________________
>> kde-mac at 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
>
> _______________________________________________
> kde-mac at 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