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