Patch: include/paths.h --> include/inn/paths.h in inn-CURRENT

[Adam J. Richter]

On Sun, 19 Nov 2006 11:50:15 -0800, Russ Allbery wrote:
>Adam J Richter <adam at yggdrasil.com> writes:

>> install /usr/include/paths.h, which conflicts with a file by the same
>> name installed by glibc.

>Don't install INN with a prefix of /usr or don't install INN's development
>headers.

	I did "./configure --prefix=/usr && make all && make install".
No user level software program should create such a conflict with such
a default installation instruction.  For that matter
"./configure --help | grep -i header" provides does not indicate
that there is even an option to disable "development headers."

>I'm not going to just move paths.h into an inn subdirectory
>unconditionally; the header itself is broken in a lot of ways and the
>whole concept needs to be redone.  When that's done, it will move into an
>inn subdirectory.

	Moving the headers now does not impede solving the problem later,
or at least the impediment is not as much as that caused by all the
build breakage that "./configure --prefix=/usr && make all && make install"
causes.

>In the meantime, I recommend simply not installing
>INN's headers if you're packaging for a distribution; this has never been
>really supported and there's more work that has to be done for it to be
>supported than just this.

	It seems to me that other users of the INN headers would
either add -I/usr/include/inn (presumably they already have a -I flag
since the headers are not installing in /usr/include), or they
could update their #include <...> statements to #include <inn/...>.
After that, they could compile to the same binaries as before, so it
would be hard to argue that they are worse off than now.  So far, I have
not seen any other changes that you want to do that are truely necessary
in order to move the headers into inn/, even if you're going to move
them again elsewhere.

	If you can show some other real breakage caused by my proposed
header file moves, that's another matter, and I'd be happy to be
enlightened about it.

	Otherwise, please consider that it has been three years since
the posting that I referred to in my original message and you say that
now you say that your time to work on INN is seriously reduced of late.
It's good that you can contribute to INN at all.  Thank you.  But, you
should step back for a moment and realize that whatever other change you
want to make in the #include hierarchy is unlikely to be imminent, so
the pain of inn clients modifying #include files twice is likely to be
less than that of "./configure --prefix=/usr && ..." breaking glibc
when people install the standard way from source.


Adam Richter