what would be the ideal `switch' a software should offer in order to
make pkgsrc happy with respect to the handling of configuration files?
Part 15.2.2 of the pkgsrc developers guide says:
15.2.2. Telling the software where configuration files are
Given that pkgsrc (and users!) expect configuration files to be in a known
place, you need to teach each package where it shall install its files. In
some
cases you will have to patch the package Makefiles to achieve it. If you
are
lucky, though, it may be as easy as passing an extra flag to the
configuration
script; this is the case of GNU Autoconf- generated files:
CONFIGURE_ARGS+= --sysconfdir=${PKG_SYSCONFDIR}
Note that this specifies where the package has to look for its
configuration
files, not where they will be originally installed (although the
difference is
never explicit, unfortunately).
I never created a package which offered the --sysconfdir switch but it
seems to me that, even with supplying an argument to --sysconfdir, `make
install' will still install all configuration files into the same place.
I added a switch to some package, maybe quagga, --example-dir, that
caused it to install the template config files to that dir. This is
separate from where it expects to read them.
Not what you asked, but I think upstream software should
have minimal config files, almost empty, for default running
if it has lengthy commented examples, great, but those shouldn't be
expected to be copied/modifed by the user, but instead a few lines put
in the user's config file.
squid is an example of this problem - one has a manual merging process
on every upgrade.
Once a package buys into this 'actual config file is tiny' and 'examples
are large' dichotomy, then the notion of a separate examples directory
makes more sense.
Attachment:
pgpRN7kz2N42n.pgp
Description: PGP signature