Re: Configurable path to look up dynamic libraries - Mailing list pgsql-hackers

From Lamar Owen
Subject Re: Configurable path to look up dynamic libraries
Date
Msg-id 01051613332404.00910@lowen.wgcr.org
Whole thread Raw
In response to Re: Configurable path to look up dynamic libraries  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 16 May 2001 12:56, Peter Eisentraut wrote:
> Lamar Owen writes:
> > I have multiple bind instances running on my main server -- it was
> > relatively easy to tell bind through named.conf where to find the
> > particular zone files for the private side (I run NAT here and must
> > maintain an inside global DNS as well as an inside local DNS), and it
> > was just as easy to tell named to use named.conf.private for the
> > private DNS side.  And all those files reside in /etc/named and
> > /etc/named.private.

> Funny, I was going to pull this example, because my zone files are in
> /var/named.

Which is arguably a better place to put them, FHS-wise.  But the point is 
this -- I can tell named where to look in a very flexible manner.  The bind 
cache, OTOH, is variable data and should go on the var filesystem....

> differently.  At some point you're going to have to present usability
> arguments.  And I notice that no one besides the RPM maintainer(s) have
> ever complained about this, presumably because the current approach is
> rather usable.

I'm not complaining.  However, I would think Oliver Elphick would like 
similar things for Debian.

As I said before, I can implement an RPM-specific solution.  But if it can 
benefit the general userbase, it shoudn't be an RPM-specific solution.

> I don't mind a global configuration file that sets the defaults for or
> overrides the local ones, because this adds a possibly useful feature.

Good.

> But spreading out the local configuration files over the disk does not
> help anyone.

Flexibility!  The admin should be allowed flexibility in installation, no?  
Of course, there are other directions the flexibility argument could go, but 
I'll not instigate _that_ battle...... :-)
- --
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7Arno5kGGI8vV9eERAkPSAKDBqXIeeV7D7L4PV6dhp7b3gYq8hACg0jS5
zegguNNxir0at+WBJ9Aexa8=
=TOrY
-----END PGP SIGNATURE-----


pgsql-hackers by date:

Previous
From: Lamar Owen
Date:
Subject: Re: Configurable path to look up dynamic libraries
Next
From: "G. Anthony Reina"
Date:
Subject: Followup to IRIX6.5 installation of PG 7.1.1