One way to deal with it though is to install this file as a resource (in /usr/share/the_appli) and when your application starts, to check if the file exists in the .config directory. If not to copy it from the resource directory.
Indeed, by rereading
https://wiki.freepascal.org/Debian_package_structure, it is clear and certain that everything which is an external resource, in read-only mode for the application (excluding documentation) such as i18n, external images to link at run-time, and therefore also read-only referential, must be in /usr/share/$(TargetFile)/ (like /usr/share/$(TargetFile)/i18n, ...).
Don't forget linux/unix is a multiuser system, once installed, an application should be usable by every user, including ones who did not exist when the application was first installed.
It is certain that I am always too influenced by Windows installations
.
I try to do the same thing again and again, more or less: ask where to install, then put everything in the same directory near the executable: database, configuration file, documentation and referentials where I can pick.
At this stage, the install should be running as root and if it has dependencies, apt installs them first. Apt install never makes changes at the user level, if, for example, the user will need some config files or directories created, that should happen when, later, they run the application for the first time.
Yes: the installation system manager is root, and only root. Even if the "original double click" to install is done by a simple user. So, I'm gonna install in /usr/share/$(TargetFile)/.
[Aside on]
However, I found on the net a trick, less clean but which can be useful: it is possible to code Bash\Shell scripts in 4 events named preinst, postinst, prerm, and postrm (they are thrown, if they are coded, during a Debian installation).
In the postinst event during the installation, all files are unpacked and therefore accessible. And Linux seems to keep a track of the user that was active (who made the "original double click" to install) before running the root installer. From this information, some people code (copy-paste from
https://unix.stackexchange.com/questions/23463/how-to-create-debian-package-to-install-files-to-home-user)https://unix.stackexchange.com/questions/23463/how-to-create-debian-package-to-install-files-to-home-user) a script like this...:
# For every user in /home/ ...
for HOME_U in /home/*?; do
# Obtain the username
USER=$( basename ${HOME_U} )
# In case the user is active (exists in /etc/shadow) ...
if [ $( grep -c "${USER}:.*:.*:.*:.*:.*:::" /etc/shadow ) == 1 ] \
&& [ $( grep -c "${USER}:.*:.*:.*:.*:.*:/bin/.*sh" /etc/passwd ) == 1 ] \
&& [ -d ${HOME_U}/.config ] \
&& [ -d ${HOME_U} ]; then
# Making sure .config/your-package/ exists
mkdir -p /home/${USER}/.config/your-package/
# with appropiate permissions
chown ${USER}:${USER} /home/${USER}/.config/your-package/
# copy what we need
cp /etc/skel/.config/your-package/x.conf /home/${USER}/.config/your-package/
cp /etc/skel/.config/your-package/y.conf /home/${USER}/.config/your-package/
cp ... /home/${USER}/.config/your-package/
# with appropiate permissions
chown ${USER}:${USER} /home/${USER}/.config/your-package/x.conf
chown ${USER}:${USER} /home/${USER}/.config/your-package/y.conf
...
fi
done
...which - in theory - allows to install a *single-user* application (certainly, against the nature of Linux). Nevertheless, some create an installation by relocating (all paths in the executable must be relative) /usr, /usr/bin, /usr/share/, ... into $HOME/.local/$(TargetFile)/usr/... and in /home/${USER}/.config/your-package/$(TargetFile).conf, for example. This seems to be more and more in the spirit of some Linux
Desktop editions (I'm thinking of new packaging formats such as snap, flatpack which are - caricaturally - somehow fractalization \ miniaturization of /usr notable directories and files into the /home/${USER}/snap_or_flatpack_or_appImage/a_package, with a level of confinement).
[Aside off]
Thanks to all!