Re: Configurable path to look up dynamic libraries
От | Lamar Owen |
---|---|
Тема | Re: Configurable path to look up dynamic libraries |
Дата | |
Msg-id | 01051613332404.00910@lowen.wgcr.org обсуждение исходный текст |
Ответ на | Re: Configurable path to look up dynamic libraries (Peter Eisentraut <peter_e@gmx.net>) |
Список | 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 по дате отправления: