Software packaging

[milli-961227]

Hi,

I've got a general question about software packaging under Linux - nothing C or C++ specific. The problem is that I cannot imagine how an executable binary knows where to find its configuration file and shared data on a target installation environment.

For example, if my package was named `myapplication', the compiled binary would most probably get installed to `/usr/bin/myapplication' (depending on the distribution and package maintainer). So far so good - but what if the binary makes use of a configuration file?

The binary could simply assume that its configuration file would be located at `/etc/myapplication.conf' and refuse to execute if it didn't exist. This would force a package maintainer to actually install the configuration to `/etc/myapplication.conf' or to patch the source code in order to make the application work - both solutions are anything but elegant.

So how does the application know where to look for its configuration (and other files)? The package maintainer could have decided to install it anywhere for whatever reason... Of course I could pass the location of the configuration file to the application via a command line option such as `--configuration=<path>' when executing it. But if the application makes also use of an image (e.g. `/usr/share/myapplication/icon.bmp') in addition to the configuration file it would need to take one more command line option - and so on.

Is there any best practice on how to solve this?
Thanks in advance!

[grumpy]

Applications have access to information about how they are run, including environment variables (particularly the PATH) and their own name (which may or may not include path information) and system API calls.

The catch is that the mechanisms to obtain information vary between operating systems (e.g. between linux variants, or between linux and BSD and windows) and in some cases, between implementations of the standard library (e.g. glibc, the gnu C library, provides slightly different means than other C libraries).

Generically, however, a common technique is to interrogate the environment in which the program is run and the supplied command line parameters for information, and use these to build a set of places (e.g. directories) to look for a configuration file, and even vary the name of the file. Then look through those places until a valid configuration file is found. If none is found, fall back on a default configuration.

Variations include;
1) looking at the command line options before (or even after) examining environment variables (for example, look in /etc before examining command line options).
2) populating the default settings before going looking for a config file, and change the configuration based on config files. (this helps the program cope if there is no config file at all)
3) check the contents of the config file for validity (for example, if the config file sets some parameter to an invalid value, ignore that value)
4) check all the config files in sequence (e.g. if one is found in /etc and another in /usr/etc and another in ~/.config) then the one in ~/.config overrides settings in /usr/etc which overrides the one in /etc which overrides hard coded defaults).

[phantomotap]

O_o

The most common technique for such "where" configuration on "LINUX" is managed through "autoconf"/similar. Even if you don't use "autoconf", you can still benefit from the approach by having such definitions in a configuration file. (You might, for example, have a `SHAREDIR' macro which is used as the leading directory for your "myapplication" images.) Yes, the approach "hardcodes" the default place to look implying a need to recompile for environments which do not follow common "FSH".

Otherwise, you'll have to guess and optionally fallback on other places to look as grumpy describes.

Soma

[milli-961227]

Thank you, I think I understand now!