Patch: include/paths.h --> include/inn/paths.h in inn-CURRENT
Adam J. Richter
adam at yggdrasil.com
Tue Nov 21 01:58:56 UTC 2006
On Mon, 20 Nov 2006 06:14:43 -0500 (EST), Jeffrey M. Vinocur wrote:
>> [...] when people install the standard way from source.
>Just FYI, the situation you are describing is by no means the "standard
>way" of installing INN. To quote from the INSTALL file:
> Installing INN so that all of its files are under a single directory
> tree, rather than scattering binaries, libraries, and man pages
> throughout the file system, is strongly recommended.
If every program imposes its author's idea of system
administration to the point where it breaks under widely practiced
standards, it will waste a lot of peoples time and create unnecessary
work dependence and security dependence on Linux vendors to do
unnecessary manual work. "./configure ..." is supposed to automate
configuration decisions so that one does not have to study each of the
1000+ software packages' authors' philosophies of file system layout.
I am not trying to tell you that the "Linux Filesytem
Standard" is perfect. For example, I acknowledge that the Linux File
System Standard impeded diskless and caused numerous unnecessary
problems with "ifconfig: unrecognized command" by ordinary users who
did not have /sbin in their paths. However, you should not dismiss
those who see advantages to having binaries in /usr/bin, libraries in
/usr/lib, and so on. For example, it is easier to tell security
programs that everything in /usr/bin can have a stricter modification
check policy and be shared across diskless clients, /etc can be placed
revision control, one can more easily put the less commonly modified
parts of a file system on flash devices that wear out after too many
writes, and so on. I imagine the "Linux Filesystem Standard" people
could give you more advocacy in that direction if you want.
So, I think that even those whose favorite configuration is
something else should agree that should agree that the advantages of
inn getting along with glibc when inn is built with "./configure
--prefix=/usr && make && make install" outweigh the advantages, if
any, of making inn under this configuration break glibc.
More information about the inn-workers