preferred place for system-wide config files

[Anonymous]

Matthew Seaman <m.seaman at infracaninophile.co.uk> writes:

> On 18/05/2010 12:56:11, Wesley Shields wrote:
>> On Tue, May 18, 2010 at 07:29:22AM +0400, Anonymous wrote:
>>> a little confusion arised from ports/146627.
>>>
>>> The Porter's Handbook defines PREFIX as the place where port should
>>> install its files including config files. However, it doesn't say where
>>> the port should try to read its config files that may not exist:
>>> LOCALBASE/etc or PREFIX/etc? Until recently I assumed such files as
>>> installed together with the port unless they belong to some other port.
>>>
>>> For example, many GNU_CONFIGURE ports look for config files under
>>> SYSCONFDIR that's usually under PREFIX/etc and some of them don't
>>> install config files nor samples. A few examples: xorg-server,
>>> subversion, git. Should such ports be modified to use LOCALBASE/etc?
>> 
>> PREFIX/etc is the correct place. Very few ports touch LOCALBASE at all,
>> and when they do it's explicitly requested. I'm thinking of bind here as
>> an example.
>
> The principle is that PREFIX is where *this* port is going to be
> installed, but LOCALBASE is where you should assume any prior dependency
> ports have been installed.

This still doesn't clarify where to look for files that are *not*
installed, e.g. config files. Such files can be created by user and only
used by the port itself when they exist. Does it matter whether they're
installed or not to choose LOCALBASE over PREFIX?

> PREFIX and LOCALBASE are virtually never set
> to different values although I do find doing that useful for tesing
> ports etc. during maintenance work.  I know there have been Qat port
> building experiments setting both PREFIX and LOCALBASE to a non-standard
> value, but I don't think there have been any tests trying to install
> each port to a PREFIX different to the LOCALBASE used for all its
> dependencies.
>
> It's also the case that some ports have to match the PREFIX/LOCALBASE of
> certain dependencies: for example various of the RT extension modules I
> maintain are like that.
>
> 	Cheers,
>
> 	Matthew