XDG base exec paths

Kai-Uwe Behrmann ku.b at gmx.de
Tue Nov 27 03:32:26 PST 2007


Am 27.11.07, 11:53 +0100 schrieb Patryk Zawadzki:

> 2007/11/27, Kai-Uwe Behrmann <ku.b at gmx.de>:
> > In danger of defining a new file hirarchy, I would first like ask how
> > would it be appropriate to place binary plug-ins for a system wide
> > service.
> > Both system side and user side plug-ins should be supported.
> > My first take was to extend the OpenICC Directory Proposal to include as
> > well binaries, but found the XDG paths document[1] does not mention
> > binaries.
> 
> What do you need user-side binaries for? Running them from a system
> service would result in giving the binaries root privileges.

I am working on a colour management system. It will feature a plug-in 
system. The plug-ins are commonly refered as CMM's. These libraries must 
be loaded by a say plug-in host. My take is there should be several hosts
possible. While colours should be secure, root privilegs seems not 
appropriate ;-)
 
> > Any hint would be welcome.
> 
> All binaries should go to either $prefix/bin or $prefix/lib{,64} -
> these are the only directories guaranteed to be mounted with exec
> rights and not shared across different architectures (as is sometimes
> done for /$prefix/share).

Is'nt this difficult with a plug-in system. 
Currently I have a config-file/binary implementation. With this the CMM 
can be installed as library in a LD_LIBRARY_PATH. 
But I want to switch to something self contained.
Scanning tousands of libraries to ask whether they are a CMM seems not 
usual practise or am I wrong with this assumtion?

> --
> Patryk Zawadzki
> PLD Linux Distribution

kind regards
Kai-Uwe Behrmann
--
developing for colour management 
www.behrmann.name + www.oyranos.org



More information about the xdg mailing list