James Gates writes: > But since we don't have to accommodate multiple versions of Slony, we > could locate the man pages in /usr/share/man (we would just need to > supply --mandir=/usr/share/man to 'configure').
OK; that'd help. > >> /usr/postgres/slony/share/slony1_base.sql > > > > > > What does "share" mean again? :-/ > > > Typically "share" directories are used for architecture independent > (shared) files. In this case SQL scripts. > > Did you have an issue with this location? Yes. My rather oblique comment was apparently missed here. The reason /usr/share exists is that it can be a mount point for shared (i.e., NFS) data. Thus, the right way to use 'share' is to create a subdirectory under that one special mount point (such as /usr/share/foo/) rather than creating your own /usr/foo/share/ off in the hinterlands. The result of having multiple 'share' distinct directories would be absurd; you'd be asking administrators to set up each one as a separate mount point, which of course they're not going to do. It's essentially the same reason why you shouldn't create "/foo/usr" but instead "/usr/foo", or why you shouldn't have "/foo/etc" but instead "/etc/foo". The apparent desire among those creating their own private file system hierarchy is to "isolate" the subsystem from everything else. I'm asserting that this desire itself is incorrect; the software should be integrated using the system's file system semantics, not in opposition. Without the chance of a separate mount point, the meaning is just plain lost, which is why I wrote that comment. The 'share' directory turns into a cargo cult. We ship these directories hoping that the planes will return. > <PREFIX>/ > bin > etc > lib > man > share The rest is probably a bit wobbly (a private xxx/etc? what's wrong with /etc and how is <PREFIX>/etc writable in a zone?), but that 'share' is just plain wrong, no matter how many others may have been led down this path or how strongly autoconf believes in it. In the grand scheme of things, I suppose it doesn't matter (what's one more mistaken directory in a sea of others?), but as a review comment: don't do that. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
