Re: Tunable sysconfdir subdirectory

[Malcolm Tredinnick <malcolm commsecure com au>]

On Mon, 2004-02-16 at 09:58, Julio M. Merino Vidal wrote:
> Hi all,
> 
> first, a bit of background: In pkgsrc (the native NetBSD's packaging system),
> the user has the ability to configure the system-wide sysconfdir by defining a
> variable, PKG_SYSCONFBASE, to where it should be.  Suppose he does:
> 
> 	PKG_SYSCONFBASE=/etc/pkg
> 
> Then, all packages install their configuration files there, so GConf2 ends
> using /etc/pkg/gconf as its configuration directory, which contains '2',
> 'gconf.xml.defaults' and 'gconf.xml.mandatory'.  All fine.
> 
> But this framework is more flexible.  It also allow users to specify the
> configuration directory on a package basis.  So, that user could do:
> 
> 	PKG_SYSCONFDIR.GConf2=/var/db/gconf
> 
> And here comes the "problem".  Passing that value to GConf2's configure script
> (through the --sysconfdir argument) means that configuration files will end up
> in /var/db/gconf/gconf/*, as sources have hardcoded in them the '/gconf/'
> subdirectory.
> 
> In pkgsrc, we workaround this by patching GConf2's sources to remove that part
> of the path on all accesses to the database.  But you guessed right: this is
> error prone, and patches get out of sync on almost every update.
> 
> My proposal is the following: remove the '/gconf/' part from all paths that
> refer to the database, and keep it centralized somewhere (that is, in the
> configure script).  I.e., change EXPANDED_SYSCONFDIR to also include
> the subdirectory part.  This alone will make things more consistent (and in my
> oppinion, cleaner), as that part of the path won't be hardcoded in the
> sources.
> 
> And then, after changing this, allow the user to change the value of the
> subdirectory.  This can be done through a configure argument (--with or
> --enable), though I feel it's an overkill, since this feature will be used by
> very few people and would otherwise confuse others.  Another way to do this
> is by an environmental variable that can be set before running configure,
> which is more obscure, but also effective.

Why do you think a configure variable is overkill? Wouldn't you set it
up so that the GConf build process behaves the way it does now by
default and when somebody passes in --with-pkgsysconfdir it is
overridden?

That is the solution I have seen (and implemented) in other places to
help out the *BSD guys.

> I'm writting to the mailing list before posting a patch as a bug report
> because I would like to know if there are chances that this gets accepted.
> If so, which approach do you prefer? configure argument or variable?
> Comments?

If it is non-intrusive in the default case (i.e. everything just works
as it does now), helping out a distribution like this does not seem a
bad thing. Of course, I carry no weight here, so this free advice may
not be worth what you paid for it. 

Cheers,
Malcolm