Re: Configurable path to look up dynamic libraries
От | Peter Eisentraut |
---|---|
Тема | Re: Configurable path to look up dynamic libraries |
Дата | |
Msg-id | Pine.LNX.4.30.0105161845490.779-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: Configurable path to look up dynamic libraries (Lamar Owen <lamar.owen@wgcr.org>) |
Ответы |
Re: Configurable path to look up dynamic libraries
|
Список | pgsql-hackers |
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. > But symlinks aren't the fix, as this is not an RPM-only issue -- there are > more than just RPM users who might want an FHS-compliant installation with > the capacity for multiple postmasters. FHS-compliancy is only going to get you so far. Where does it stop? Next thing somebody comes around and claims that BSD hier(7) wants it all 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 don't mind a global configuration file that sets the defaults for or overrides the local ones, because this adds a possibly useful feature. But spreading out the local configuration files over the disk does not help anyone. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
В списке pgsql-hackers по дате отправления: