When building ganglia as a FreeBSD port, I apply a number of patches and
run some sed scripts to deal with the fact that the following paths are
hardcoded into ganglia:

/etc/gmetad.conf
/etc/gmond.conf
/var/lib/ganglia/rrds

The problem with this is that FreeBSD ports expect to find their config
files in $prefix/etc and BSDs use /var/db rather then /var/lib for
application databases.  I would like to correct this problem.  I have
mostly complete patches to do so (not including since they don't fully
work yet).  In order to do this, the doc and config files that mention
these paths become .in files so configure can update them.

I've dealt with most of the C code, but the gengetopt code is causing me
some problems because gengetopt can't generate .in files yet.  There are
three solutions to this problem.  1) stop using the default= support in
gengetopt and do in ourselves.  2) Add a dependency on gengetopt to the
build so we can use a cmdline.ggo.in file.  3) Make gengetopt generate
.in files.

Option 1 is fairly easy though it removes the somewhat useful default
output from the command line.  Option 2 is as fairly easy, but it
adds a build dependency.  That's not a major issue on FreeBSD, but
we don't want the depends to get out of hand.  Option 3 doesn't work
except by hand yet, but I've submitted a patch to the gengetopt mailing
list (or at least I will once the moderator wakes up and completes my
subscription.)  I think it is a bit ugly since makes two .in files.

I think options 1 and 2 are more or less a tie for me.

As part I the path overhaul, I plan to make the default prefix
/usr/local like with most GNU software, install the config files by
default in $prefix/etc/ and have the code that switches on $host set the
new varstatedir variable to /var/db in the FreeBSD case.  The default
value of varstatedir will be /var/lib.  This will require the configure
line in ganglia.spec to be changed from:

./configure --prefix=/usr

to

./configure --prefix=/usr --sysconfdir=/etc

Does this sound like a reasonable thing to do?  Any opinion on how to
deal with the cmdline.[ch] files?

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

Attachment: pgpC8A8vwrESm.pgp
Description: PGP signature

Reply via email to