Hi, Ken -
> It is not that simple. These configuration files were special cases
> where the setting depended on the distro ... since there is no
> distro-specific logic in configure.in any more they cannot simply be
> moved by command-line options to configure without moving a whole lot of
> other stuff.
Right; the idea was that distro-specific stuff would be in Makepkgs or
other such wrapper scripts, which would invoke .../configure with the
distro-favoured --foodir=BARPATH options.
> > Yeah, cleaning it up fully is quite a bit of make-work.
>
> I favour this approach. The work is boring, but low risk ... just the
> sort of thing we could assign to a retired person ... 8^)>
You won't find me discouraging a volunteer! :-)
One tricky aspect could require some packaging scripting, that being
the migration of config files from the old to the new locations.
> > ($PCP_SYSCONFIG_DIR is already defined, just not used, whoops.)
>
> This defaults to /etc/sysconfig ... which smells like something Redhat
> specific ... although as it is not used, perhaps it should be culled.
Right; probably redefined as /etc/pcp by default (and if any RH
directory purist speaks up, they can use
--with-pcp-sysconfig-dir=/etc/sysconfig/foobar).
> [...]
> My vote would be for changing all references in the code from
> $PCP_VAR_DIR/config to $PCP_ETC_DIR or better, introducing
> $PCP_SYSCONF_DIR which would have the same value is $PCP_ETC_DIR but
> would allow the uses in the code base to remain identifiable if we need
> to revisit this at a later date.
Makes sense. (Or just use $PCP_ETC_DIR throughout.)
> [...] The crontab enties really should only be installed if one is
> running the system versions of pmlogger or pmie [...]
(I assume you mean their configurations rather than code.) Perhaps we
could provide a pmlogger-setup subpackage that activates the default
logs & rotation crontabs.
- FChE
|