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

[Kai-Uwe Behrmann]

Am 26.11.05, 10:57 -0800 schrieb 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. 

Hal,

CUPS can tell where ist has its profiles to Oyranos. Of course as long as 
it considers Oyranos insecure compared to its own rules, it can not access 
other locations visible to Oyranos. On the other hand, Oyranos does not 
support TCP/IP.
But the source profile should be visible to CUPS anyway by embedding into 
the printfile. For untagged data it would be desireable, CUPS knows 
what default profiles are set on the client machine. But could be the 
toppic of a later version.

> 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.

Bob,

ah, you think it needs to be relocatable regarding its paths.

The other side of the path configuration is the location of the 
configuration itself. There are the pathnames stored. Currently it is 
/etc/kdb/ and  ~/.kdb/ . 
For instance: ~/.kdb/user/sw/oyranos/paths/path1
How would this fit in the network scenario you paint?

> > 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.

regards
Kai-Uwe Behrmann
                                + development for color management 
                                + imaging / panoramas
                                + email: ku.b at gmx.de
                                + http://www.behrmann.name