Patch: include/paths.h --> include/inn/paths.h in inn-CURRENT
davidsen at tmr.com
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 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
> 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"
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 tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
More information about the inn-workers