> On 13 Feb 2003, Oliver Elphick wrote: > > > What your comments strongly suggest to me is that projects like > > PostgreSQL and pine, along with everything else, should comply with FHS; > > then there will be no confusion because everyone will be following the > > smae standards. Messes arise when people ignore standards; we have all > > seen the dreadful examples of MySQL and the Beast, haven't we? > > Actually FHS says the opposite. If the distribution installs PostgreSQL > then the config files belong in /etc/postgresql. If the admin does then > they belong in /usr/local/etc/postgresql. FHS is out of their tree. If > PostgreSQL or any other package is not critical to the basic operation of > the operating system, it's config files shouldn't be polluting /etc.
I suspect you may be conflating BSD usage with Linux usage here... The point isn't of being "critical to basic operation of the operating system;" it is of whether or not the software is being "package-managed" or not. One of the operating principles in FHS is that "/usr/local" is an area that the distribution should never "pollute." And so, a "package-managed" PostgreSQL installation should never touch that area. Looking at FHS, for a moment: http://www.pathname.com/fhs/2.2/ 3.7.1 Purpose /etc contains configuration files and directories that are specific to the current system. 3.7.4 Indicates that "Host-specific configuration files for add-on application software packages must be installed within the directory /etc/opt/<package>, where <package> is the name of the subtree in /opt where the static data from that package is stored." 3.12 indicates: /opt is reserved for the installation of add-on application software packages. A package to be installed in /opt must locate its static files in a separate /opt/<package> directory tree, where <package> is a name that describes the software package. Then comes 5.1, on /var /var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files. It would make most sense, based on FHS, for PostgreSQL information to assortedly reside in: - /etc/opt/postgresql or /etc/postgresql, for static config information; - Binaries could assortedly live in /usr/bin or /opt/postgresql; - Logs should live in /var/log or /var/log/postgresql; - Data could assortedly live in /var/lib/postgresql, /var/opt/postgresql; - PIDs should live in /var/lock or /var/lock/postgresql. None of these choices should come as any spectacular shock to anyone; there are an assortment of sets of bigotry out there surrounding the Proper Purposes of /opt and /usr/local, and there's probably enough wriggle room there to avoid overly enraging anyone that (for instance) felt calling a directory "/opt" would make someone deserving of carpet bombing by B-52s. Interestingly, the Debian install of PostgreSQL somewhat resembles this, with, assortedly: /etc/postgresql /etc/postgresql/postgresql.conf /etc/postgresql/postmaster.conf /etc/postgresql/pg_hba.conf /etc/postgresql/pg_ident.conf /etc/init.d/postgresql /usr/share/doc/postgresql /usr/share/man/man1/pg_ctl.1.gz /usr/lib/postgresql /usr/lib/postgresql/bin/postgres /usr/lib/postgresql/bin/enable_lang /usr/lib/postgresql/bin/initdb /usr/lib/postgresql/bin/initlocation /usr/lib/postgresql/bin/ipcclean /usr/lib/postgresql/bin/pg_ctl /usr/lib/postgresql/bin/pg_dumpall /var/run/postgresql (This is obviously incomplete; this just gives the flavor that there are files in a reasonably rational but diverse assortment of places.) Note that the server software hides in /usr/lib/postgresql/bin; it's not stuff you should normally run from the command line, so, quel surprise, it is stashed somewhere that's unlikely to be in your $PATH. Stashing _everything_ in /var/lib/postgres would seem a tad surprising. Mind you, if I need to manage 4 instances on one box, I might very well install several instances some place custom, say /opt/postgres, or similar, and in that case, it's probably preferable for everything to reside clearly underneath that, and for my custom backup scripts to work in that area. But if I'm managing 4 instances on one box, it should be quite evident that I'm going well beyond what any packaging system is likely to be prepared to handle. Again, quel surprise. -- (reverse (concatenate 'string "gro.gultn@" "enworbbc")) http://www3.sympatico.ca/cbbrowne/linuxxian.html "Of _course_ it's the murder weapon. Who would frame someone with a fake?" ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster