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.

Adam Richter


More information about the inn-workers mailing list