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

Bill Davidsen davidsen at
Mon Nov 20 19:18:15 UTC 2006

Adam J. Richter wrote:
> On Sun, 19 Nov 2006 11:50:15 -0800, Russ Allbery wrote:
>> Adam J Richter <adam at> 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."

Actually, I think that what you are doing might be appropriate for a 
distribution vendor, who would presumably overcome the issues, but 
installing ANY application in /usr is questionable practice for end 
users. I see many users using /usr/local, other /var or /opt, but going 
in /usr is a bad idea because you may cause conflicts and name clashes. 
Oh wait, you found that out already. ;-)
>> 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.
I suspect a warning message from configure would be appropriate in some 
way. I haven't tried your patches in combination with a safer prefix, 
nor looked too hard at what would happen if an update was taking place 
on an installed system, but I think the issue is better documented with 
a "may cause serious conflicts" warning than "fixed" to accommodate 
something other than the recommended install practice.
>> 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.

I really think the issue is thinking that "the way I want/need to do it" 
is the "standard way," in general keeping complex and non-critical 
applications away from system namespace.

bill davidsen <davidsen at>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

More information about the inn-workers mailing list