kdelibs4 doesn't respect startupitem

[mkae (Marko Käning)]

I'd suggest some patch like the one attached (UNTESTED THOUGH, since I haven't got enough time right now) in order to let the port respect the installation wide settings for startupitem.

[mkae (Marko Käning)]

UNTESTED patch in order to enable the port to respect startupitem settings

[pixilla (Bradley Giesbrecht)]

I didn't see your ticket when I opened #36751, maybe we opened our tickets at the same time.

Try this patch patch-kde-kdelibs4.diff​ to solve your problem.

[pixilla (Bradley Giesbrecht)]

Has duplicate #36751

[NicosPavlov]

Committed patch from ticket #36751 in r99119 to respect startup.install.

[mkae (Marko Käning)]

Although my configuration file /opt/macports-test/etc/macports/macports.conf defines

startupitem_type none

kdelibs4 installs the plist file's link under /Library/LaunchAgents/

$ ls -1l /Library/LaunchAgents/
lrwxr-xr-x   1 root admin   67 Oct 27 23:31 org.macports.kdecache.plist -> /opt/macports-test/Library/LaunchAgents/org.macports.kdecache.plist

which is why I think kdelibs4 needs another rework'''

---

Looking closer at this it seems to me that there are two configuration parameters handling one and the same thing:

1) startupitem_type (which could be set to "none")

2) startupitem.install (which could be set to "no")

To me it looks like kdelibs4 just handles case 2, while I am trying to make use of case 1...

Why is that or what am I missing?

[mkae (Marko Käning)]

This fix worked in my case. But as I mentioned before I consider these two cases unnecessarily built-in in macports.

[mkae (Marko Käning)]

Replying to mk@…:

Looking closer at this it seems to me that there are two configuration parameters handling one and the same thing:

I created the MacPorts-base-related ticket #36770 for the specific startupitem(_type|.install) issue.

[mkae (Marko Käning)]

I realized by now that I'd need an even more sophisticated approach to install the launch-agents, since I have minimum 3 MacPorts installations up and running at a time, where 2 of them make use of KDE4 applications (/opt/macports-test and /opt/clean-slate). With the current approach of a single plist file for the lauch-agent it doesn't work.

I'd need an agent per installation, i.e. 2 links to the 2 plist files in /Library/LaunchAgents/

$ ls -1l /Library/LaunchAgents/
lrwxr-xr-x   1 root admin   67 Oct 27 23:31 org.macports.kdecache_opt_macports-test.plist -> /opt/macports-test/Library/LaunchAgents/org.macports.kdecache.plist
lrwxr-xr-x   1 root admin   67 Oct 27 23:32 org.macports.kdecache_opt_clean-slate.plist -> /opt/clean-slate/Library/LaunchAgents/org.macports.kdecache.plist

[mkae (Marko Käning)]

Just now I noticed in my log that kbuildsycoca4 seems to use a cache file which doesn't seem to be specific to the MacPorts installation, which makes the use of more than one KDE4-MacPorts-installation even more complicated:

10/28/12 2:00:38 PM	org.macports.kdecache[30577]	kbuildsycoca4 running...
10/28/12 2:00:38 PM	org.macports.kdecache[30577]	kbuildsycoca4(30577)/kdecore (KSycoca): Trying to open ksycoca from "/private/var/tmp/kdecache-marko/ksycoca4"

Hmmm, it looks as if KDE4 itself needs to be told to use a different - installation specific - prefix for the cache in one of its config files. "/private/var/tmp/kde-cache-${user}" isn't sufficient. It should be something like "/private/var/tmp/kde-cache-${prefix}-${user}".

[mkae (Marko Käning)]

In the meantime I've understood that there's more to it than just the cache issue when trying to run several different KDE's on one machine.

Of course all the configurations are kept in one place:

~/Library/Preferences/KDE

which doesn't allow in itself the use of more than one KDE installation. :-(

[sharky@…]

Cc Me!