Move proj.ini to /etc

[sebastic]

proj.ini is currently installed in /usr/share/proj, but since it's a config file that users may want to edit it should be installed in /etc instead.

Packaging systems like RPM & dpkg will automatically preserve user changes by installing new versions of the file with a suffix (if it was modified).

[rouault]

While your suggestion makes sense from a Linux point of view, the current location for proj.ini was justified in https://proj.org/community/rfc/rfc-4.html
"""
A text configuration file, installed in ${installation_prefix}/share/proj/proj.ini (or ${PROJ_LIB}/proj.ini) will contain the URL of the CDN that will be used. [...]

The rationale for putting proj.ini in that location is that it is a well-known place by PROJ users, with the existing PROJ_LIB mechanics for systems like Windows where hardcoded paths at runtime aren’t generaly usable.
"""

[kbevers]

@rouault perhaps we could add /etc as one of the dirs where proj.ini is searched for on Unix-like systems? Or would that also mean that PROJ will also look for grids and other resource files in /etc?

[sebastic]

If proj.ini is not a config file, i.e. users are not expected to modify it and it just stores the default values outside the binaries, it can stay where it is.

Users should then be discouraged from modifying the file and always use the environment variables or relevant function calls to change the defaults.

[rouault]

The file is intended to be sometimes modified.

We cannot just hardcode /etc, since that would be inappropriate for installations in /usr/local for example

I've looked a bit at https://www.gnu.org/prep/standards/html_node/Directory-Variables.html and https://cmake.org/cmake/help/v3.4/module/GNUInstallDirs.html, and there's apparently a autoconf
${sysconfdir} and cmake SYSCONFDIR variables for that.
For autoconf, ${sysconfdir} defaults to ${prefix}/etc, but a --sysconfdir=DIR switch exists for ./configure. I guess that for classic installation at the 'root', ./configure should then be passed --sysconfdir=/etc --prefix=/usr ?
This directory should also be passed as a #define so that PROJ looks for the file at the right place.
proj.ini look up should be done in a dedicated way as we don't want other resource files to be looked for in the "etc" directory

I'm a bit concerned though for Conda-like installations where the package is relocated and we need to rely on relative paths, so we'd need also to add a relative look up strategy for the file.

So all in all, from my perspective, this is a non completely trivial development effort (code + impact on both build systems) for one single file. Impacts on packaging. And a more complicated story to explain to users. There has been precedent of users hacking in $PROJ_LIB to modify the no-longer existing epsg file to add their custom entry in it, or of course adding their own grids.

[kbevers]

So all in all, from my perspective, this is a non completely trivial development effort (code + impact on both build systems) for one single file. Impacts on packaging. And a more complicated story to explain to users. There has been precedent of users hacking in $PROJ_LIB to modify the no-longer existing epsg file to add their custom entry in it, or of course adding their own grids.

I think that is good enough reason to don't change things. Especially not now in the last minute before 7.0.0. I'll close this issue, but it may be worthwhile to reopen at a later stage if proj.ini is used for more settings than currently.

[gdt]

I will chime in that the installation of a config file into share is seriously broken. I can see that it was judged too hard to fix, meaning that the risk due to fixing outweighs the benefit, i don't think this ticket should be closed.

With standard packaging system behavior, any changes made will be lost on upgrade, and if modified the file will show up as damaged when checking installed package integrity.

It seems clear that autoconf's sysconfdir mechanism (and the cmake equivalent) should be used, both in makefiles and in substituting in where it's read from. The convention is to use /etc when prefix is /usr, and to use ${prefix}/etc otherwise. That is how just about every program out there deals with config files. As for installations that are not bound to a prefix at build time, they need to dynamically find things, but ${BUILDROOOT}/etc seems just as easy as ${BUILDROOT}/share.

(Sorry for not reading the RFC and catching this earlier, but it never would have occurred to me that user-modifiable config files were in other then $sysconfdir. This pattern is not Linux, but essentially universal on all POSIX-like systems and defined by the GNU coding standards. This dates back to at least 2.8BSD, and I think probably Seventh Edition.)