[Openicc] Do we want /usr/local/share/color/icc as a third profile directory ?

[Bob Friesenhahn]

On Sat, 26 Nov 2005, Kai-Uwe Behrmann wrote:

>> Linux is just one operating system among many.  It is a Unix-type system.  So
>> while standard paths should be established for Linux distributions,
>> independently maintained packages which target POSIX (rather than just Linux)
>> systems need to use a common design which exactly supports the Linux paths
>> when formally installed, but ensures sane operation when installed to some
>> other location.
>
> I dont understand if your above text is a confirmation or want to bring
> an additional aspect to attention?

It is both. :-)

> Maybe a commandline tool should help a arbitrarily installed package to
> tell Oyranos about the path it intents to install its profiles. something
> like:
> oyranos-add-path --path_name="$PREFIX/share/color/icc"
> [--key_name="sane_profile_path"]

My point is that if Oyranos is installed to use a different 
installation prefix (other than /usr), that it should not 
automatically (by default) look in /usr/share/color/icc at all.  When 
the package is formally installed, an option could be supplied to look 
there by default as well but this decision is made by someone who is 
familiar with the target environment.  Oyranos is just one package. 
The convention to use should be established across similar packages.

In large organizations I have seen an administration heirarchy that 
looks like:

  o machine/network administrators (always have root)

  o software/tools administrators (sometimes have root, limited rights)

  o end users (hardly ever have root)

So it may be that the software is installed by a high-level 
administrator, or the software may be installed by an 
intermediate-level administrator.

If the software is installed on a network server, then one 
installation of the software and profiles can serve 5000 hosts, which 
serve 5000 (or more) user accounts.  In this case, it is highly 
unlikely that the software will appear directly under /usr, and it is 
unlikely that the administrator will want any random files on the 
system interfering with consistent package operation.

Bob
======================================
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/