G'day Frank.
On Sat, 2012-11-24 at 13:54 -0500, Frank Ch. Eigler wrote:
> kenj wrote:
>
> > [...]
> > Recent relocation of some critical configuration files out of /etc
> > and into /var/lib/pcp/config meant that the marking of these files
> > in Debian packages was lost and they were being unconditionally
> > overwritten during an upgrade.
> > [...]
>
> IMHO, it would be more proper to have all configuration files under
> $sysconfdir.
Well some of them used to be in /etc/<some-pcp-dir> for debian builds
but were recently moved when configure.in was rearranged.
I tend to agree in principle, but one could possibly argue either
way ... the usage text from configure suggests
--sysconfdir=DIR read-only single-machine data [PREFIX/etc]
--localstatedir=DIR modifiable single-machine data [PREFIX/var]
Now the files that are explicitly marked as "configuration" files to the
debian and rpm packaging are all ones we ship, expect they may well be
modified by a sys admin and thereafter we treat them as read-only.
To move them to $sysconfdir we'd have a little work to do.
OPTION A
Introduce $PCP_SYSCONF_DIR to expose $sysconfdir via pcp.conf and then
move everything currently below $PCP_VAR_DIR/config/<foo> to
$PCP_SYSCONF_DIR/<foo>.
This touches vastly more files than the ones in the current
"configuration" files list, and would involve changes to 310 lines of
code/script/qa, although the changes can largely be automated.
OPTION B
Keep the existing list of "configuration" files, and be more surgical.
This will split PCP configuration data between $sysconfdir and
$PCP_VAR_DIR/config.
B.1. Simple cases where we have a dedicated variable in configure.in and
parameterization in pcp.conf to drive symbolic reference and possible
relocation. The change would be to configure.in and a makefile where
the containing directory is created/installed.
pmcd/pmcd.conf
pmcd/pmcd.options
pmcd/rc.local
pmproxy/pmproxy.options
pmie/control
pmlogger/control
Note that these will need multiple "pcp" directories below $sysconfdir,
namely pmcd, pmlogger, pmie and pmproxy.
B.2. Cases that _should_ be handled as in B.1. but we do not have
dedicated configure.in variable to define the path, and so we'd need to
do that to uncouple the symbolic reference from $PCP_VAR_DIR
pmie/stomp
B.3. Cases that are on the list and really are not configuration files
in the sense of the ones above ... these are shipped and never expected
to be changed locally. I don't know what to do about these ... if they
are to be moved to $sysconfdir then we'll need treatment like B.2. else
leave them where they are
pmie/config.default
pmie/crontab
pmlogger/config.default
pmlogger/crontab
It would be nice to clean this up for once and for all ... let's see if
we can reach consensus on what's the "right" thing to do.
|