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

[Craig Ringer]

Bob Friesenhahn wrote:
> On Sat, 26 Nov 2005, Kai-Uwe Behrmann wrote:
> 
>> Hello,
>>
>> about symlinks:
>> My intention for Oyranos is to reject them.
>>
>> about flatness:
>> Oyranos include subdirectories to allow some kind of structurising. But a
>> convention how to make use of is not yet formed.
>>
>> The above suggested thierd standard directory would be ok with me for 
>> unix
>> alike systems except osX.
> 
> 
> When following the BSD/GNU standards which have driven directory layouts 
> for many years, the /usr/local/share/color/icc path makes sense in that 
> with the default installation path it is $PREFIX/share/color/icc.  From 
> an installed package's perspective this is the same as 
> /usr/share/color/icc if the package is installed with $PREFIX=/usr. This 
> means that support for /usr/local/share/color/icc is an absolute 
> requirement for packages installed using common default conventions 
> ($PREFIX=/usr/local) but only if they are not configured to use a 
> non-default installation prefix.
> 
> Packages which support profiles should always check 
> $PREFIX/share/color/icc and should prefer (check first) that directory 
> over /usr/share/color/icc since /usr/share/color/icc may be under 
> different administration.  This will include packages installed under 
> OSX unless they include specific OSX knowledge.
> 
> It is debateable if a package installed with $PREFIX=/usr should also 
> check for profiles in /usr/local/share/color/icc.

It probably should. Consider the Linux case of a user having installed 
an application with an RPM. They now want to add system-wide profiles 
that all applications will see. Messing with /usr/share/color/icc is 
arguably a bit ugly, since on Linux /usr/share is typically 
package-managed. It would be more appropriate for the application to 
support scanning _both_ /usr/share/color/icc and /usr/local/share/color/icc.

I'd argue that an environment variable should also be supported to 
permit administrators to configure paths such as 
/some/network/volume/prepress/ICCProfiles to be scanned as well. This 
approach is fairly common with libraries and applications that can pull 
in settings from multiple sources, and makes sense so long as each 
supported location has a clearly defined and separate purpose, eg:

/usr/share/color/icc - for profiles installed by packages;

/usr/local/share/color/icc - for profiles installed by the admin,
                              or that came with software
                              compiled/installed locally on the machine;

$PREFIX/share/color/icc - To be scanned in case the app comes with
                           bundled profiles and is installed at a non-
                           default prefix;

ICC_PROFILE_PATH - Additional directories to search to preserve the
                    sanity of the network administrator.

Other packages do this (in fact, `ld.so' comes to mind) and it solves a 
real problem without, in my view, introducing excessive complexity. 
Sound reasonable?

--
Craig Ringer