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

[Hal V. Engel]

A specific example from a past thread in this list may raise some other issues 
related to this.  A while back there was a very long thread about printing 
systems that included information about the beta version of CUPS (1.2.x).  
This version of CUPS will handle a color space transformation to a printer 
color space using a profile passed in by the calling application.  For 
security reasons CUPS 1.2.x will only use profiles that are located in the 
CUPS directory.  Actually it only requires that these be logically in the 
CUPS directory since it will allow these files to be in a linked location.  
But that is really beside the point since to use the CM stuff in CUPS the 
users application needs to pass CUPS a printer profile that is either 
physically or logically located in the CUPS directory structure.

If something like oyranos is used to catalog and manage profiles when a user 
application requests a printer profile that will be passed to CUPS oyranos 
will have to pass back the path/file name of a profile that is located in the 
CUPS directory structure.  So this is more complex than two vs. three profile 
directories.  IE. /usr/share/color/icc and ~/.color/icc 
vs. /usr/share/color/icc, /usr/local/share/color/icc and ~/.color/icc. 
 
On Saturday 26 November 2005 10:32 am, Bob Friesenhahn wrote:
> 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/
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc