problem with kdecache when having muliple macports installations

[Ryan Schmidt]

On Oct 26, 2012, at 16:18, MK-MacPorts at techno.ms wrote:

> I am running multiple MacPorts install at the same time, and they reside in their own directories like
> 
> 	/opt/local/
> 	/opt/macports-test/
> 	/opt/clean-state/
> 
> but some files are joint below 
> 
> 	/Library
> 
> like e.g. kdecache's 
> 
> 	/Library/LaunchAgents/org.macports.kdecache.plist
> 
> This leads to the problem that I cannot install the agent and thus also not the whole port for more than one MacPorts installation.
> 
> In my case I successfully upgraded on /opt/clean-slate/
> now that I wanted to do the same on /opt/macports-test/
> I receive this error message during upgrade:
> ---
> --->  Activating kdelibs4 @4.8.5_0
> Error: org.macports.activate for port kdelibs4 returned: Image error: /Library/LaunchAgents/org.macports.kdecache.plist already exists and does not belong to a registered port.  Unable to activate port kdelibs4. Use 'port -f activate kdelibs4' to force the activation.
> --->  Computing dependencies for oxygen-icons
> ---

All of the above sounds correct and normal.


> This is bad, since I definitely want to upgrade also on the other MacPorts install. I'd want to update the agent's plist file manually later…
> But the current state of the portfile doesn't allow this. So I guess we'd need a variant no_kdecache, don't you think? :-)

We don't use variants whose names begin with "no_" anymore, ever since MacPorts gained the ability with registry 2.0 to remember disabled variants.


> I'm not able to send a portfile diff right now, but perhaps I am able to do that in a few days time.
> 
> But who knows, Nicos, perhaps you can come up with a solution already earlier.

I set "startupitem none" in macports.conf in all my secondary MacPorts installations to avoid the installation of LaunchDaemons. Since LaunchAgents are not installed by MacPorts but are installed manually by individual ports they might not respect that setting; if they don't, maybe they should be fixed to do so, since I'm not sure of another way we could handle this.